OK, so given Daniel's and Keren's suggestions, here's what I'll do:
I will create three new modules: core, exp, and modeller. All developers will have commit privileges to the core and exp modules. Modifications to the kernel will still need to go through me. The other specific modules will remain as they currently are - each with a given owner (Keren for em and domino, me for modeller).
The core module will contain most of the code that most users and other projects use. Thus, most of the concrete classes currently in the kernel (headers in subdirectories, not the top-level directory - e.g. ConnectivityRestraint, RestraintSet, Daniel's nonbonded lists) will move into the core module. API changes, deletions from, or additions of new restraints, etc. to core (but not simply new methods to existing classes, or cleanups of internals, etc.) should be announced on imp-dev *before* the code is committed. (A general outline of new features is fine - I just don't want to wake up one day and find 20,000 lines of code in some entirely new set of classes.)
Code in the core module can be at various levels of maturity. The only requirement is that the test cases pass "most of the time". (The general rule of thumb should be that the nightly builds do not break for more than 3 consecutive days.) As Daniel suggested, immature code should be marked in a Doxygen group so that users can be aware.
The exp or experimental module is for code that is (scientifically) experimental in nature. I will put particle refiners, cover bonds, tunnel singleton score, and wormlike chain in there. This code should still have test cases, of course, and be marked if it is immature just like core is, but won't be built or tested as part of the nightly builds, so there is less requirement that the tests pass all the time. If a bunch of classes are envisaged for a given project (e.g. NPC dynamics, a new optimizer, etc.) then probably the best thing is a distinct module for that, where you'd have more flexibility, or even something entirely external (e.g. Assembler).
Finally, the modeller module will contain what's currently in modeller.py, plus anything else that requires Modeller, so that the kernel and core can be built and tested without needing Modeller around. (It will also get some additional Modeller-specific restraints which I'll need to entice users away from Modeller.)
I will decide what goes in each module. Movements between modules should be exceedingly rare. It should certainly *not* be the case that somebody uses exp simply to write dodgy code that doesn't work, and then moves it to core when the bugs are fixed. If stuff really needs to be moved between modules, *I* will do it.
I will have the nightly build system email imp-dev if the nightly builds fail. The culprit will then hopefully fix the problem ;) (with my assistance if necessary).
I will create a Bugzilla instance to keep track of IMP bugs and wishlist items. Bug fixes should, of course, come with a testcase to ensure the bug stays fixed, and to some extent document the nature of said bug.
I will also work with Keren to put Assembler into the automatic build system.
I am reluctant to set too many rules, but there is an obvious requirement that things rely reasonably stable, so that developers can concentrate on the science and not on updating their code to work with the most recent changes. It is my responsibility to keep things that way, so I will revert patches (or users ;) if they cause extreme breakage. I'll be relying on everyone to take care with their code and its testcases. So while I cannot make everybody happy, I can do the next best thing and make everybody equally unhappy (hopefully only moderately so ;).
Obviously there is a bunch of stuff to do, and I am not going to spend my holiday weekend working on it. Plus, I will be in Chicago for most of next week. So probably things will be ready to move forward at the start of the following week.
If anybody can point out an obvious problem with this solution, I may have to think about (and delay) things some more. Otherwise, have a relaxing and sunny Labor Day. ;)
Ben