Boost logo

Boost :

From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-03-22 23:27:02

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at