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.