On 06/02/2015 11:58 AM, Niall Douglas wrote:
On 2 Jun 2015 at 21:28, Peter Dimov wrote:
The precedent for handling this is very well understood.
Can you please cite specific examples of this "precedent"?
If during the early part of review it becomes obvious Rejection votes are occurring due to presentation problems, the precedent is to withdraw the library from review, make the fixes, and start the
I don't recall this happening. Despite what some people might want to think, the review process is not an equatable voting process. It is a process in which a competent review manager solicits community feedback and then makes an educated decision. The review manager's job is not to tally votes.
review again with the fixed edition. I certainly don't like libraries changing during review, and I also don't like two editions of a
Abel has not submitted a second version for review by the community. He was gracious enough to show what the other version might look like at your prodding. The more amazing thing to me is that the original version is the older Boost directory structure and some reviewers are confused by that.
I think peer reviews are very like academic paper peer reviews: it's
Boost reviews have nothing to do with academic paper reviews.
Not submitting a library in the correct directory structure is guaranteed to create problems for some reviewers, and is easily predicted before a review begins. Lack of CI testing is another. This is why I wrote up that Best Practices Handbook so for C++ 11/14 libraries we can hopefully get more of the boxes preticked in the future before reviews of C++ 11/14 libraries begin.
I've only been active in the Boost community for 10-years, but let me help correct some of your assertions. It is not uncommon for libraries to need a restructure of directories and namespaces *after* approval. The goal is that authors present a very high quality library without having to completely boostify it before finding out if it will be accepted. Directory structures and namespaces are not a requirement of a review. CI testing is also not a requirement for a review to be successful. You are free to voice your opinion and to write documents that promote it; however, you cannot force your requirements onto the process. michael -- Michael Caisse ciere consulting ciere.com