Important: OWNERS files

[Ben Goodger (Google)]

All,

In the more than two years since the Chromium project started, the number of people contributing has grown immensely. With this expansion has come many challenges, the most important of which is ensuring the continuity of our product and development principles. As our project has grown in size and scope, the code-base has begun to show signs of fatigue. We have tried to emphasize care for the commons, but those proclamations can seem vague compared to the very real need to fix a certain number of bugs or get your feature done for an upcoming milestone.

I speak for a number of leads on the team when I say that we've had a hard time keeping up with the pace of change. As we expand the scope of Chrome in many different directions, it's critical that we consider even more carefully the design of the core code. As we do this it is important to rely on the most experienced engineers in each area.

After some discussion with the team last year, we have decided to roll out an implementation of a OWNERS file system. An OWNERS file lives in a directory and describes (in simple list form) whose review is required to commit changes to it. OWNERShip inherits, in that someone listed at a higher level in the tree is capable of reviewing changes to lower level files. We are currently working on the tooling to support this in the code review workflow, but we plan to start seeding the tree sooner with OWNERS files so that we may start to realize some of their other benefits.

OWNERS files provide a means for people to find engineers experienced in developing specific areas for code reviews. They are designed to help ensure changes don't fall through the cracks and get appropriate scrutiny. OWNERShip is a responsibility and people desginated as OWNERS in a given area are responsible for the long term improvement of that area, and reviewing code in that area. OWNERS will be incented to limit the scope of their module (clearing up APIs and directory structures) to make their workload manageable.

Much of Chromium's practices are modeled on Google's own internal engineering practices. OWNERS files were one area where we explicitly diverged. Why? In the past I had been concerned about the social effects of OWNERS files - I had been concerned about territoriality which can sometimes creep in any collaborative project. We had encouraged the development of "alternative" means of change notification, and so we have WATCHLISTS. WATCHLISTS proved insufficient for many of us however. Darin and I discussed the issue, and talking with other senior engineers decided that OWNERS files seemed like a more comprehensive answer. Working with this fantastic team though for the past few years I am convinced that we are socially capable of handling such a system and dealing with any challenges that arise at the team leadership level.

I am going to push a document to the website this week that describes the particulars of how OWNERS files work. I will update this thread when the document is live.

When the OWNERS system is fully integrated with the code review workflow and ready to become a mandatory part of our process I will send out another email to this list.

Regards,

-Ben

[Ben Goodger (Google)]

Update:

This document describes OWNERS files and OWNERship:

http://www.chromium.org/developers/owners-files-1

-Ben