[continued from previous message] 
  
 experienced developers, who are not that interested in being told what 
 workflow they should be using and are more interested in how to gradually 
 add specific tools in a way that doesn't badly increase the level of 
 friction involved in their current work. That advice will probably need to 
 be at least somewhat tailored to how they're currently working and their 
 preferences, as opposed to how you wish they were working or how you 
 prefer to work yourself. 
  
 Anyway, the tl;dr is that I have worked on teams before where code review 
 was required for every change, and that workflow was both annoying and 
 resulted in lower-quality code reviews when they actually mattered. I'm 
 not likely to use it again without a really good justification for why a 
 specific project needs that level of overhead and friction. This does not 
 mean that I dislike code review! I both ask for and write code reviews on 
 a regular basis and they're valuable for thinking more deeply about tricky 
 bits of code. They're also valuable as a training tool for developers who 
 are new to a particular code base. We should use them where appropriate, 
 including for new contributors. But we shouldn't turn them into an 
 off-putting religion. 
  
 -- 
 Russ Allbery (rra@debian.org)               
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)