Avoid disrupting the work of other developers

To work productively, developers need to control when they see changes and which changes they see. The appropriate mechanism for this purpose is a view. Developers can modify an existing config spec or create a new one to specify exactly which changes to see and which to exclude.

To implement this policy, you can also require developers to write and distribute the config spec rule that filters out their checked-in changes. The following are sample config specs:

To select your own work, plus all the versions that went into the building of Release 2:
```
element * CHECKEDOUT
element * REL2
```
To select your own work, plus the latest versions as of Sunday evening:
```
element * CHECKEDOUT
element * /main/LATEST -time Sunday.18:00
```
To select your own work, new versions created in the graphics directory, and the versions that went into a previous build:
```
element * CHECKEDOUT
element graphics/* /main/LATEST
element * -config myprog@@12-Jul.00:30
```

To select your own work, the versions either you (jones) or Mary has checked in today, and the most recent quality-assurance versions:

element * CHECKEDOUT
element * ’/main/{ created_since(06:00) && ( created_by(jones) ||
created_by(mary) ) }’
element * /main/{QAed=="TRUE"}

To use the config spec include facility to set up standard sets of configuration rules for developers to add to their own config specs:
```
element * CHECKEDOUT
element msg.c /main/18
include /usr/cspecs/rules_for_rel2_maintenance
```