After following the recent discussion about voting down LL because of possible future submissions of other libraries, I've had some thoughts about the process. I do not believe votes against inclusion of a library should be counted unless they are for specific technical reasons. This would mean that a vote against a library must state what changes the library author needs to do to change it to a vote for inclusion. This could be anywhere from "I'm uncomfortable with this set of features" to a very specific change to a header file. But it should refer to something along the lines of:

1. lacking features
2. design decisions
3. unpolished, underdeveloped areas
4. incomplete or incorrect documentation
5. refactoring

It should in all cases be restricted to things that can be addressed directly by the library author. I value Boost as a place were new ideas and methods are developed, voting against a library on any grounds other then its usefulness and completeness works against the process of discovering the best solutions. We should control it, but overlapping functionality and a desire to maintain backward compatibility should not keep new and useful ideas from the Boost libraries. It must be kept in mind that being accepted into Boost is a beginning, the libraries I have used have all evolved /after/ they were accepted.