Subject: [boost] [outcome] How to write a review considering the broad scope
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 14:31:27
> Typically, the outcome of a boost review is
> etiher "accept" or "acceppt, but fix this and that", or "reject". Now,
> during this review, my feeling is we are just trying to design big parts of
> the library. There is so many open questions, that one cannot get te sense
> of the final shape. To reject it would be sending the wrong message that we
> do not wat the problem to be solved, or that the solution is wrong. But it
> is not wrong: it is just "I can make it whatever you want". To accept it on
> condition that it has a different interface, is like accepting something
> else than what we see. We can do it technically, but it feels wrong. I am
> confused here, I admit.
This review is surely exactly like any normal review!
Before giving your review, you would:
1. Read the changes already implemented to develop branch at
2. Read the changes I've accepted from peer review feedback at
3. If you like the library after all those issues were implemented,
recommend acceptance, possibly conditional on further things you
personally think need to be changed yet.
4. If you dislike the library after all those issues were implemented,
recommend rejection, preferably with a list of what should be in the
library instead. Nobody wants a flawed design in Boost, myself included.
The review manager is ultimately the person who decides based on
everyone's reviews. Your review is there to help them decide. I
certainly wouldn't worry about recommending rejection if you think the
presented design + fixes in the issues would result in a library you
don't want to see in Boost.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk