Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2024-11-10 17:14:41


Christian Mazakas wrote:
> The thing is, you're the one deciding that what I said wasn't "serious",
> Klemens.

It wasn't. If I were the review manager, I would have thought the same.

I don't want to pick on you too much because, in principle, you didn't
do anything wrong in your review, apart from the insistence that it
ought to have been counted as "serious". You are fully within your
rights to leave whatever review you like, with the awareness that it
would be counted commensurately.

Saying that you reject the library because it should have been designed
"sans I/O" so that it could be used with any asynchronous backend,
including your own (which has 0.2 users), requires justification.

You need to explain what you think a sans-I/O library in this domain
would look like. You need to give examples of existing libraries that
can be used with any asynchronous backend, including your own. You
need to explain why you think the value of the library lies in the I/O-
independent part, rather than in the I/O management part.

> Look, it was just a poorly managed review.

To an extent, yes. In principle, it's the review manager's job to give
you the benefit of the doubt and to try to coax a serious review out
of you, by for example asking the above questions.

I feel like we've lost some implicit knowledge of what a review
needs to look like, and what a review summary needs to accomplish.

Stated concisely, this knowledge is:

If, five years from now, someone would like to know why a library
has been accepted or rejected, he _only_ needs to read the review
posts and the review summary, and should come away with the
correct understanding of what happened.

For the reviewer, this means that your review needs to be
self-contained. It's not a starting point for a discussion. Nobody is
obligated to ask you clarifying questions, and there should be no
missing parts that you fill in later in subsequent posts.

This means that if you have questions about the library that you
feel need to be answered by the author (or the review manager),
you should ask these questions _before_ you write your review.

For the review manager, it means that the review summary needs
to contain all the information the manager has taken into account
when coming to a decision. If there were discussions out of band,
they need to be summarized. If there were discussions _on the list_
that haven't made their way into formal reviews, they need to be
summarized.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk