Iterative platform for Code Review

Question

EDIT: For those unclear on what problem this proposed change aims to address, consider the fundamental nature of code review, or any similar process (novel writing, sketching/drawing, building Rube Goldberg machines ... ). The process is inherently and ideally iterative. In fact the most important thing to note is the word "process" as opposed to "event". Currently the platform of Code Review is ideal for handling "events" but not "processes". I am proposing below an attempt to more effectively handle the process.

Original post below:

Code Review appears to have the same essential function and platform as other parts of Stack Exchange such as Stack Overflow. I would expect a code review process to be iterative, in a way that a Q&A process would not be.

I would propose a shift of the Code Review platform to allow for successive iterations of the same project without necessitating the creation of new, unlinked posts. Something similar to the format of exercism.io would seem ideal.

Answer 1

It's hard for me (even as a regular user of Code Review) to evaluate this proposal, because it doesn't explain what the problem is. What exactly is the trouble that would be avoided by this proposal? Is it:

1. You posted some code for review, and fixed the problems identified in the answers, and your fixed code would have benefited from another review, but you didn't realise that you could have the code reviewed again by posting a new question?

2. You posted some code for review, and fixed the problems identified in the answers, and you would have liked the fixed code to be reviewed again, but you couldn't figure out how to do that?

3. You were reviewing someone's code, but you didn't realize that they had already fixed the problems and posted a new version of the code for review in another question?

4. You were reviewing someone's code, but you didn't realize that another reviewer had already pointed out the same problems in an answer to a previous question?

5. Something else?

Before we can evaluate a proposed solution, we need to understand the problem it is intended to solve. (Just as we can't review code unless we understand the problem that the code is intended to solve.)

Update: after some discussion in comments, it seems that the problem is similar to #2 above:

6. You posted some code for review, and fixed the problems identified in the answers, and you would have liked the fixed code to be reviewed again, but the idea of posting a follow-up question seemed counterintuitive to you.

That seems like a genuine problem to me. Nearly everyone who wants a follow-up review starts with the intuition that the way to get one is to edit the post to substitute (or append) the revised code. So I think there is some evidence that being required posting a follow-up question is genuinely counterintuitive.

There is a very good reason, however, that we insist on doing it like this. In the early years of the site, we allowed posters to edit their question to include revised code. But this led to an unsatisfactory situation, both for reviewers (it was unpleasant to put in lots of work writing a review, only to find when you came to post it that the code had changed under your feet and your review comments were no longer applicable) and for posters (because it was never clear which version of the code each reviewer was reviewing). Having separate posts for separate revisions solved this problem, but introduced the counterintuitive experience.

(Nonetheless, lots of posters do in fact find it possible to post follow-up questions. I get more than 3,000 results for a search on "follow-up".)

The proposed interface changes might solve this problem, but they might not. It is hard to be sure without experiencing it in practice. In the proposed interface, I can imagine that it might still feel unpleasant as a reviewer to find that your review is out of date before you post it. I can also imagine a pathology that might develop in some cases whereby an enthusiastic poster could keep submitting new versions of the code faster than reviewers can get to grips with the old versions. The current situation has the merit of freezing the question to a particular version of the code, giving reviewers time to write their reviews.

It's important to note that Stack Exchange (the company) doesn't provide special features for the individual sites in the network. There is a limited amount of "skinning" in terms of customizable text, images and colours, but otherwise the sites all run on the same code base. So realistically speaking and based on their past behaviour, Stack Exchange is unlikely to implement anything like your proposal. For this reason I think it would be worth considering alternative approaches that are more practical.