with apologies to Pierre Bayard, who wrote much more amusingly about how to talk about books you havn't even read and covered all the territory and more.
First, you've seen the title and abstract, so you can extrapolate from your deep knowledge of the area what a good paper on this topic would look like. of course, as an editor or esteemed member of the program committee, you would no doubt write such a paper but someone else must necessarily have made some small or even more significant errors in framing the problem, or overlooked much related work that could have led them to a better result, and so you must point out your previous work to them in some detail.
Second, you've seen a talk about this subject recently, and so of course this paper is really too late to the table, and can't bring anything new, deeper, or surprising that wasn't already in the talk.
Third, you read a monograph, book, or even survey paper of this area recently, and the topic is completely as dead as a dodo - there really can't be anything new to mine here anyhow.
Fourth, this paper has been submitted to this venue, which isn't very good anyhow, and you resent the extra work, so you expect it is full of mistakes and the abstract looks like it was written in Word anyhow, so it can't be any use.
Fifth, the idea sounds good, so you better reject the paper and finish your work on the same topic super quick or else you will have been gazumped.
Sixth, the words in the abstract look very much like words in wikipedia that you've seen recently, and you strongly suspect plagiarism, so you cut and paste a review you wrote of a similar paper.
Seventh, the title includes a word spelled in an unusual way, and you guess that the author's first language is Cobol, and that therefore they have had no new ideas since 1971, although some of those ideas did make quite a bit of money, which means they really don't need any more publications or a bigger H-Index.
First, you've seen the title and abstract, so you can extrapolate from your deep knowledge of the area what a good paper on this topic would look like. of course, as an editor or esteemed member of the program committee, you would no doubt write such a paper but someone else must necessarily have made some small or even more significant errors in framing the problem, or overlooked much related work that could have led them to a better result, and so you must point out your previous work to them in some detail.
Second, you've seen a talk about this subject recently, and so of course this paper is really too late to the table, and can't bring anything new, deeper, or surprising that wasn't already in the talk.
Third, you read a monograph, book, or even survey paper of this area recently, and the topic is completely as dead as a dodo - there really can't be anything new to mine here anyhow.
Fourth, this paper has been submitted to this venue, which isn't very good anyhow, and you resent the extra work, so you expect it is full of mistakes and the abstract looks like it was written in Word anyhow, so it can't be any use.
Fifth, the idea sounds good, so you better reject the paper and finish your work on the same topic super quick or else you will have been gazumped.
Sixth, the words in the abstract look very much like words in wikipedia that you've seen recently, and you strongly suspect plagiarism, so you cut and paste a review you wrote of a similar paper.
Seventh, the title includes a word spelled in an unusual way, and you guess that the author's first language is Cobol, and that therefore they have had no new ideas since 1971, although some of those ideas did make quite a bit of money, which means they really don't need any more publications or a bigger H-Index.
