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 https://github.com/ned14/boost.outcome/blob/develop/doc/md/08-changelog.md 2. Read the changes I've accepted from peer review feedback at https://github.com/ned14/boost.outcome/issues 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/