My two cents: I think this should be a little more liberal. At beta 1, freeze the addition of new features but continue to tweak the implementation with code clean-ups, additional tests, algorithmic improvements, and better docs.  For many of the devs (and users), the first time we get to exercise and interact with some of the new features is during the beta — that is our chance to improve and stabilize it before it goes out the door.  If a new API proves awkward in some way, the time to find out and improve it is during the beta.  Ideally, we would like both the API and implementation to mature a bit before the release (first draft != final copy).  A release candidate is different — that is close to an across-the-board freeze.  Once the release happens, bug fixes and documentation tweaks will continue to be checked in for the next micro-release.