Institute a norm around security and performance retrospective reports, reinforcing appropriate incentives
In T114419: Event on "Make code review not suck", @ori made the case that we should move to a similar ethic to the operations/puppet repo, where self-merges are allowed, but responsibility lies with the whoever merged the patch. Such a move would require a lot more discipline and know-how than has traditionally been exhibited by everyone who currently has +2 rights ("everyone" being the key word). Even for the people that are have the know-how, the discipline can be difficult because of our current traditions.
One ethic that would help us develop the discipline required for self-merging would be TechOps-style retrospectives/postmortems for all serious security and performance issues. These wouldn't be about assigning blame, but about building trust and helping us collectively learn from our mistakes. In the aftermath of a serious mistake, a well-written retrospective would help build trust in the author, and would provide the author with deserved esteem.
One anti-pattern we should avoid: dumping this on WMF specialist teams. The Security-Team and Performance-Team s at WMF can play an essential role here, but they wouldn't be responsible for writing the reports. If we instituted this, their responsibility would be to establish the practice, guide committers who need assistance completing reports, and identify incidents for which retrospective reports are appropriate. Additional responsibilities these teams could take on: quarterly retrospective review meetings (similar to the ones @greg runs) and other aggregate reporting, such as percentage of incidents deserving reports that don't have them.
One day we might also ask for "technical debt retrospectives", but let's crawl before we walk. ;-)