Simplify CODEOWNERS further, but require extra scrutiny for MRs affecting data integrity
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3590840. -->
Reported by: [wim leers](https://www.drupal.org/user/99777)
Related to !1120
>>>
<h3 id="overview">Overview</h3>
<p><span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3558237" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3558237</a></span> made <code>CODEOWNERS</code> a lot simpler. It made it more pragmatic.</p>
<p>3 observations:</p>
<ol>
<li>It has helped to increase velocity. Especially with multiple teams working in parallel on various Canvas features.
</li><li>The most pain we've seen in the ~6 months since then are in the area of CI: flaky tests etc. @justafish has been the main driver towards fixing that velocity killer.
</li><li>The most risk we've seen since then is in the area of data integrity: it's fine for new HTTP APIs to be added, the UI and CLI to move fast, but risky changes to config schema (e.g. <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3571536" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3571536</a></span>) and the component instance updater infrastructure (e.g. <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3587024" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3587024</a></span> and <a href="https://git.drupalcode.org/project/canvas/-/merge_requests/692/diffs#note_749869">https://git.drupalcode.org/project/canvas/-/merge_requests/692/diffs#note_749869</a> for #3577603)
<p>→ If we ship one release that corrupts or loses user data, we'll have lost the user's trust!
</p></li></ol>
<h3 id="proposed-resolution">Proposed resolution</h3>
<blockquote><p><strong>Being intentional about which areas require more thorough review is what makes it possible to move fast everywhere else. Those two things aren't in tension, they enable each other. For example, protecting against data integrity issues is worth putting some extra effort against because recovering from them once they reach production is slow and expensive in a way most bugs aren't.</strong>
</p></blockquote>
<p>— @lauriii, capturing the intent better than Wim :)</p>
<ol>
<li>Simplify further! Because this file has not been kept up-to-date anyway. Which means the only reliable way to <q>facilitate seeking input from maintainers who have the most experience in a particular area</q> (quoting <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/canvas/-/work_items/3558237" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/canvas/-/work_items/3558237</a></span>) is now possible only by looking at the commit history of a file and then looking at the people most credited on those commits
</li><li>Require >=3 people to approve when an MR touches data integrity-related parts.
</li><li>Require @justafish to approve when modifying <code>.gitlab/ci/*</code> or <code>.gitlab-ci.yml</code>
</li></ol>
<h3 id="ui-changes">User interface changes</h3>
<p>None.</p>
issue