The goal of this web site is to help C++ programmers produce C++ code libraries as good as those libraries accepted into Boost
Most of the information contained here is my personal view which has been shaped by my experience as developer of the Boost Serialization Library.
In no way should any information found on these pages be construed as reflecting any "official" policy or recommendation of Boost.
The Boost review is the essence of boost.
Boost libraries need more good reviews
More quality library submissions are needed
There aren't really enough reviews for many packages.
Many libraries really aren't ready for review.
When the review comes up, there's a two week period and everyone who wants to participate has to adjust to this period. I'm sure lots of people don't participate because of scheduling issues.
Writing a library is very difficult and an immense amount of work. This diminishes the number of libraries submitted.
This web site is intended to address these problems.
Library authors prepare their submissions in accordance with the guidelines set by this web site and upload their submission. The submission is subjected to a pre-review to verify that it meets minimum standards for consideration to be part of Boost. These standards include:
Documentation and completeness
Note that this pre-review doesn't address subjective aspects such as the quality of the submission, usefulness, etc. It only addresses those things that can be verified by following a checklist. The submission is made available for download and a project page is opened for this submission. This project page will be used to keep a record of information regarding the submission as it becomes available. This information will include:
Reports of bugs
Requests for features
Observations on design and implementation
Any other useful and relevant information
Users are encouraged to run the libraries tests and upload the results to the library test statistics. Submissions remain available at least until they are a.
More people will have downloaded and tested the submission and will have provided feedback and reviews on the library's "issues" page.
For some libraries, "issues" history will make it obvious that the library would not pass the formal review process. The whole review process can be skipped in this case.
For some libraries, the "issues" history will make it clear that acceptance is a "no-brainer". The review process will be much simpler in this case.
Everyone who has an interest will be able to contribute to the review process even if they can't commit to a specific time/date window.
The review manager will have a wealth of information available that he doesn't have now. This will make the process much easier than it is now.
Authors can get feedback before the submission is reviewed while there is still an opportunity to make adjustments.
Libraries can start small and have features added incrementally until they are ready for review.
A library feature set can be developed in accordance with experience of real users. This should make the library more likely to get a better review and diminish the amount of effort expended on features for which there is little demand.
User feedback may motivate authors to spend more effort finishing the library.
Test results from a variety of platforms will be available to help authors make their library portable.