Does there exist any conditions for closing iterative review questions as duplicates?

Question

As far as I know, we simply don't close questions as duplicates on Code Review. I think it's even been mentioned that a Code Review duplicate has to be basically an exact copy & paste of the previous question.

To some degree, this makes sense. Code Review questions and answers tend to be highly specific and tailored exactly to the user posting the question. It's hard for a question to be a duplicate on Code Review.

But how about iterative review questions? Can these sometimes be considered duplicates? If so, what sort of criteria do we have for iterative review questions being duplicates or non-duplicates? Is there a minimum amount of changes that need to be made to the source code? Is there a minimum amount of time that needs to elapse between asking? Should the previous question have an answer marked accepted?

I understand it's very unlikely a black & white issue, but I'm not certain that these are all necessarily non-duplicates. It's probably a gray area, but I think it'd be useful to discuss some guidelines on this topic.

Answer 1

More or less, I'm of the thought that the answers the asker receives takes care of this.

There are cases where users are actively adding additional features and it makes sense if it all leads to a related task to have an iterative series. Review focused on a, implement suggestions and create A, add b + c, post new question Abc.

Sometimes, follow up questions simply implement the suggestions given in a preceding question's answers, and nothing more. People simply tend not to answer these questions. The answers they do receive focus on minor aspects of the code and a reasonable asker should realize that there simply isn't much more to improve short of writing code for them.

There are borderline cases in which users post follow-up questions based on comments on a question that was not answered, or inexplicably post follow-ups on unanswered questions. On one hand, they really ought to simply edit their question, on the other hand if they made significant changes and still want their older implementation reviewed, which could potentially point out some other misconceived step not present in their newer implementation, and an answerer is up to the task, I don't think it's a problem that merits defining a rule against it.