...

• Each code area has an owner and at least one reviewer
• The owner has pretty much final say in what goes in to his area (subject to project leader override in rare cases)
• Anybody who is not the owner must get pre-commit approval from the owner before committing changes to the owners code
• Trivial changes such as copyright changes etc, require a curtesy note / warning to the owner
• The reviewer is the primary go-to developer whenever the owner needs a review
• The owner should review all change sets which go into the code area, but can do so post-commit
• The owner does not need pre-commit reviews but should make the reviewers aware of the code that he is changing
• For complicated or risky reviews, the reviewers should wait a reasonable amount of time before approving to give interested parties who might be in other time zones a chance to spot problems

...

It is not necessary that every developer is owner of something. Not being an owner doesn't mean that you have no responsibility -- perhaps your work is cross cutting and affects many different areas (like mnemonics or accessibility). In these cases you may own some small part but need to get reviews for the code that touches other owner's areas. Or maybe you are an architect and own very little but work all over the platform. In such cases you may not be an owner for the places where you are principally working.

A fundamental idea behind this strategy is that the owner and reviewers must have a shared model of how the code is changing, the bugs that are being fixed and who is making changes.  Neither the owner nor the reviewer should be surprised but a code change.

Technical Discussions and Code Reviews

...