From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-27 11:38:12
Personally I've a lot experience with the review process.
The trick is to see the review process not as the beginning but the end of
of the process.
a) make available a useful package in the vault, sandbox and you're personal
b) make your package useful - even though it may be incomplete
c) make sure it includes enough documentation so that its idiot - proof to
use. This documentation has to include tutorial and examples so that an
interested party can get utility from it right away. This also includes
having it ready to paste into the users boost tree
d) when related issues come up on the list - respond with postings to direct
interested parties to your package
This will give you certain benefits.
i) You will get lots of feedback before the review
ii) You will get lots more testing.
iii) If you keep your documentation upto date you will already have a lot of
questions/objections pre-answered before a formal review. This saves lots
My personal experience in a nutshell
a) make library and post as above
b) keep updated based on feed back from users
c) draft #9 - reviewed by boost - and soundly rejected.
d) after licking my wounds - reviewed the review and re-did the package
according to he "new spec"
e) draft #18 - reviewed by boost - accepted without dissent.
The serializaton package was large than most (maybe than any other?) so this
is sort of a worst case scenario. The main point is that the review is the
culmination of a process. Most of the issues that come up should have come
up earlier. The object of the above suggestion is to try to get as much as
possible done in the pre-review stage. Also this addresses the issue of
time available for a review. Review dates are announced well in advance so
review time shouldn't be an issue.
(P.S.) I've not addresses post review acceptance issues even though they are
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
> John Torjo wrote:
> > It's so funny, during reviews, everyone comes up with his own better
> > version of the reviewed library.
> That's one of the reasons we have reviews, is it not?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk