== Summary
Institute a norm around security and performance retrospective reports, reinforcing appropriate incentives
== Background ==
In {T114419}, @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 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.
#ArchCom's role would be as an enforcement and appeal board should committers in certain areas of the code demonstrate a longstanding lack of discipline. We already have a policy implicitly granting this authority ([mw:+2](https://www.mediawiki.org/wiki/Gerrit/%2B2)). Here's what it says as of 2016-01-15:
>Anyone can propose a revocation discussion, any architect in the Wikimedia Foundation (currently Brion Vibber, Tim Starling, Roan Kattouw, Trevor Parscal, Gabriel Wicke and Mark Bergsma) can sign off on a revocation for technical or social reasons, and the Wikimedia Foundation's most senior engineering manager (currently Lila Tretikov) or the manager's delegate can sign off on a revocation for emergency security matters or obvious policy breaches.
"revocation for technical or social reasons" is basically another way of saying "this committer isn't trusted anymore". Why that might be:
> [Commit privileges are] a big deal. Your merge could cause Wikipedia or other sites to fail. It could create a security vulnerability that allows attackers to delete or corrupt data, or to gain access to private information. And in the more common case, it could cause technical debt to increase if the code doesn't have tests, is poorly implemented or poorly socialized. You're therefore required to read this entire document and carefully review all the relevant links in it before using +2.
In light of this, we //might// also ask for "technical debt retrospectives", but let's crawl before we walk. ;-)