Re: [boost] [outcome] How to write a review considering the broad scope

Subject: Re: [boost] [outcome] How to write a review considering the broad scope
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-26 15:57:09

Le 26/05/2017 à 16:31, Niall Douglas via Boost a écrit :
>> 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 issue list don't tell us what will be done.
I would like to have your opinion on what Boost.Outcome should become 
after the exchanges we have had and before been accepted.
Which Boost.Outcome library you would like to have in Boost?

> 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.
>
If you believe we should have a review after everything has been updated 
your decision is more important than the one of the review manager.

We need however to have a sort of consensus of what we want at the end.

In the committee we do some straw-pools (SF, F, N, SA, SA), but this is 
more complex when we are not in face to face. If I was you I will try it 
for some of important points.

Best,

Vicente