-2
\$\begingroup\$

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.

mockup of proposed layout

| | | | | |
\$\endgroup\$
  • 4
    \$\begingroup\$ There is an established process for "successive iterations" on this platform: Iterative Reviews, also known as Follow-Up Questions. Could you clarify what exactly you'd like to see improved? \$\endgroup\$ – Vogel612♦ May 4 '18 at 21:14
  • \$\begingroup\$ I'd like to eliminate the Follow-Up Question in favor of having a single post with successive iterations in one place. Tracking the progression and evolution of thinking in an iterative process is often informative. Making that easier seems like a reasonable goal. Separating iterations into unique posts that are not obviously linked seems counter to the process of iterative review. \$\endgroup\$ – Matthew Stevenson May 4 '18 at 21:23
  • 3
    \$\begingroup\$ So what problem are you solving? I now somewhat understand your goal. Why are you trying to get there though? What's bothering you? A great meta question doesn't only describe that, but makes the readers care about the problem. It then guides them along your thought process to the solution. Maybe you want to edit your question to include some of that so readers can follow along more easily? \$\endgroup\$ – Vogel612♦ May 4 '18 at 21:31
  • 4
    \$\begingroup\$ Would Code Review have been a platform on it's own, this could've been a good idea. Being part of the SE network has it's perks, but in this case, it limits. \$\endgroup\$ – Mast May 4 '18 at 21:47
  • 2
    \$\begingroup\$ Yeah, in one sense this is an interesting idea, but I just don't see it being possible. I don't know whether to give this question pie-in-the-sky support, or to be realistic and say "this will never happen". \$\endgroup\$ – rolfl May 4 '18 at 22:13
  • \$\begingroup\$ @Mast, I am ignorant of the underlying limits on SE sites. Would there be no possibility of introducing a tab structure that puts each iteration with its associated comments under one tab? Then the "post" or "question" has a single ID and each iteration is treated as a "sub-post" or "sub-question". \$\endgroup\$ – Matthew Stevenson May 4 '18 at 23:31
  • \$\begingroup\$ @MatthewStevenson If you could find a use-case for this also for other sites, I think the SE team might be more interested. Maybe you could also include an image mock-up for how you are intending this to look? \$\endgroup\$ – Simon Forsberg May 5 '18 at 14:36
  • \$\begingroup\$ @SimonForsberg: I'll put a mock-up together today. What is the most appropriate way to post it, editing the OP or as an Answer? \$\endgroup\$ – Matthew Stevenson May 6 '18 at 15:06
  • \$\begingroup\$ I have added the mockup image to the OP. As for use-case of non-code review sites, one that comes to mind is handling questions that either become irrelevant or require different answers when the technologies involved change. So rather than dealing with a highly rated question that was accepted and was once correct but now two years later is obsolete, you leave that and re-version the question with the new answer. \$\endgroup\$ – Matthew Stevenson May 6 '18 at 19:36
  • 3
    \$\begingroup\$ @MatthewStevenson - For Code Review I am supportive of the concept... but the use-case for other sites you've suggested is... a stretch. On other sites it makes sense to have different iterations of answers for the same question as new solutions become available (for example, in Java, "How to write a string to a file?" would be done with a FileOutputStream, then NIO, then Files.write with newer versions respectively), but on Code Review we have a new Question too.... is the use-case compatible? \$\endgroup\$ – rolfl May 6 '18 at 19:59
  • \$\begingroup\$ @rolfl I would agree that for other sites I haven't come up with the best argument, I would suggest, however, that this change would solve the issues raised in this MetaSO answer. It would preserve the "correct" answer for the version of the underlying technology at the time of the original query (for "legacy" queries in the future) but still allow for updated answers to be highlighted for the current version of the underlying technology. \$\endgroup\$ – Matthew Stevenson May 6 '18 at 22:39
5
\$\begingroup\$

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:

  1. 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.

| | | | | |
\$\endgroup\$
  • \$\begingroup\$ I think people who don't see the problem are those that take a more narrow view of what StackExchange is or should be. Taking Code Review as an example, the narrow view is that the site/service exists only to provide access to volunteers with expertise in the area of concern to a questioner. Once the transaction between questioner and experts is concluded there need be no more thought given to it. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 16:16
  • \$\begingroup\$ I think the broader view is that SE plays a dual role: the primary transactional role above, along with a secondary role as a repository of such transactions. The secondary role is arguably more impactful, as it serves any number of people looking for answers or opinions on similar problems. My proposed change improves the experience for the secondary role. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 16:18
  • \$\begingroup\$ I'm sorry, I was not complaining. Your post expressed that you did not see the problem. You seem intent on the notion that the problem is a specific issue I could not resolve. What raised the issue for me was indeed being told not to edit or addend code after suggestions were made but to create a new post. As that seemed counterintuitive to the way review processes should work I decided to suggest a way to improve that process. It seems self evident that SE uses the same transactional approach across all sites, when some sites might benefit from a different approach. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 16:46
  • \$\begingroup\$ Yes, that would be fair, though I think the implication of the proposed change is wider than making the process more intuitive. I think it would improve the actual process to see the edits and response to suggestions. This would also allow reviewers to clarify in cases where the questioner makes changes that missed the intended mark. I also take issue with the suggestion in your #2 that I could not figure out how to do it. I could obviously create another post and even link to the original, but that process seems less than ideal. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 16:54
  • \$\begingroup\$ Thanks for taking the time to update your answer. It seems that the limitations of SE do make this unlikely to happen. That said, I would suggest that as reviews would be linked to the iteration, a review would not be "out of date" for the iteration even if there are subsequent iterations. Somewhat like a tutorial specifically for Rails v4 would be out of date for someone using Rails v5 but not for someone using v4. In fact, alternative reviews of an older version might change the approach taken entirely with subsequent iterations. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 18:20
  • 1
    \$\begingroup\$ @MatthewStevenson: Just out of interest, what is your experience of writing code reviews? (On the reviewer side.) What tools have you used? \$\endgroup\$ – Gareth Rees May 7 '18 at 18:29
  • \$\begingroup\$ I would classify myself as late-beginner stage self-taught programmer. My main experience with code reviews comes from exercism and some very kind one on one work with the user kotp on exercism. In a previous life, however, I was a copy editor for a publishing company. The process seems similar: draft-feedback-revise-feedback...publish. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 19:41
  • \$\begingroup\$ @MatthewStevenson: The analogy with copy-editing is interesting, but I wonder if might be more misleading than helpful? The thing you work on in copy-editing is the text, which is the product that gets published and read by the end user. But in code review, you work on the source code, which often does not get published, and even when it does it is hardly ever read by the end user. \$\endgroup\$ – Gareth Rees May 7 '18 at 19:57
  • \$\begingroup\$ I think the similarities might be deeper than you suggest. In both cases the goal of the exercise is first to accomplish the task, second to do so in as efficient and concise a manner as possible, and third to do so in as elegant and idiomatic a manner as possible. Also, assume the text being copy edited were a screenplay. Even though the "published" product is not the text, the editing process is still integral. I am curious what you think the ideal code review process should be. \$\endgroup\$ – Matthew Stevenson May 7 '18 at 20:12
  • 3
    \$\begingroup\$ @MatthewStevenson: In my experience in the industry, code rarely gets reviewed more than once. This is because there are diminishing returns on effort from re-reviewing code, and there are always competing uses for the effort (in particular, testing). If code is regularly needing re-review, something has gone wrong with the development process, for example the programmer has been given a task that's too hard for them. Things are different here on Code Review, where many posters are beginners, and so might want re-review. (But personally I think they would be better off writing something new.) \$\endgroup\$ – Gareth Rees May 7 '18 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .