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 website 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 of time. 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. Robert Ramey (P.S.) I've not addresses post review acceptance issues even though they are non-trivial. RR "Peter Dimov" <pdimov@mmltd.net> wrote in message news:003c01c4ba7b$55765a60$6501a8c0@pdimov2...
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: http://lists.boost.org/mailman/listinfo.cgi/boost