Change Details

== 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, per the [mw:+2 policy](https://www.mediawiki.org/wiki/Gerrit/%2B2) (as of 2016-03-31): > Anyone can propose a revocation discussion, the Wikimedia ArchCom can sign off on a revocation for technical or social reasons, and anyone authorized by Wikimedia Foundation's Board of Trustees (e.g. WMF's Director of Technical Operations) 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. ;-)

== 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 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. #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, per the [mw:+2 policy](https://www.mediawiki.org/wiki/Gerrit/%2B2) (as of 2016-03-31): > Anyone can propose a revocation discussion, the Wikimedia ArchCom can sign off on a revocation for technical or social reasons, and anyone authorized by Wikimedia Foundation's Board of Trustees (e.g. WMF's Director of Technical Operations) 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. ;-)

== 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 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. #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, per the [mw:+2 policy](https://www.mediawiki.org/wiki/Gerrit/%2B2) (as of 2016-03-31): > Anyone can propose a revocation discussion, the Wikimedia ArchCom can sign off on a revocation for technical or social reasons, and anyone authorized by Wikimedia Foundation's Board of Trustees (e.g. WMF's Director of Technical Operations) 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. ;-)