I don't see any reason to limit code review to one person. Ideally there would be a group with volunteers that do it, so there is no pressure, or dependence, on one specific person. This group would not be limited to people that are experts on the system, as a lot of bugs can be spotted, and suspicious code be flagged, by people familiar with the used language. Critical commits can also be identified and pushed to people more familiar with the code. In an ideal world, everyone would be an expert, but let's be pragmatical here, in-perfect review is better then no perfect review.
Jeroen De Dauw
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
I agree with Jeroen, and I think that using some unit testing framework would
be a good step toward addressing this. My current tests work similar to what
Jeroen describes, with the possible difference that I use a copy of the SMW
Sandbox for doing it, thus covering more cases. I also have numerous test
pages that I created during the development of the features, but thee tests do
not have a consistent format (and especially hardly any documentation of the
The main problem with getting more structured tests running is the amount of
resources that this requires. How can we find programmers to help in building
such a test suite?
Code review is another issue. A basic problem is synchronisation: while normal
development tasks can often be executed at any time, code review should be
done shortly after a commit. So whoever is doing it needs to be available
every day (or maybe every second day) for a short time. In contrast, I often
see volunteer developers (including myself) aggregating their work and
devoting larger consecutive chunks of time to more intensive coding. For
reliable reviewing, we would need someone with a quite different scheduling.