The NetBsd project (as well as many other OpenSource projects) has a mailing list to which is sent a note about every commit to the CVS repository (in other words, every change made to the system). This is similar to the RecentChanges page in wiki. As well as a list of changed files, each message contains a set of CVS diff commands that you can cut and paste into a terminal window to see the changes. Most, possibly all, NetBsd developers subscribe to this list.

A culture has grown up around this and made this a key component in the InformalCodeReview process for NetBsd. Developers skim through the list and, any time they see a change of interest to them, they go examine it and discuss it (on another list appropriate to the topic) when necessary.

I do this at Blink, too, and I find this, at least on smaller projects, to be quite helpful. I get a general idea of where changes are happening in the system, which gives me some warning of things that might affect me, and my informal reviews let me pass expertise I have on to other members of the team at the time it's most useful.

I find this not to take up much time. I spend perhaps fifteen minutes per day going through the messages and looking at changes that I'm interested in. Any time spent discussing changes is on top of that, but discussion is usually a quick (3-5 line) e-mail message or a minute spent poking my head around a door and chatting with a developer.

CurtSampson
----
Some issue trackers like Insecticida do this automatically.
----
Where I work, we cannot submit changes to the repository without seeking a code review from someone first.  Code review notices, which do include the CL log message, are (supposed to be) forwarded to a project-specific mailing list.  The problem is, with as many developers as we have working on the project at once, we get ''so many'' code review notices that reading them, nay, even ''skimming'' them, would dominate the bulk of your day.  As a result, most people here choose to archive the messages immediately, and read through them ''only'' when problems occur.