Skip to main content
Commonmark migration
Source Link

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer whose code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no longer needed!).

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer whose code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no longer needed!).

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer whose code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no longer needed!).

typo fixes
Source Link
janos Mod
  • 113.1k
  • 31
  • 68

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer who'swhose code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no lonterlonger needed!).

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer who's code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no lonter needed!).

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer whose code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no longer needed!).

Source Link
rolfl
  • 98.2k
  • 4
  • 117
  • 238

The Edit Review queue is notorious for people making mistakes in the process. The problem is almost entirely related to the fact that answer edits are much rarer than question edits.

Code Review has unfortunately got a lot of robo-reviewers in this queue, people who see a code edit - and auto-reject - without first checking whether the code is part of an answer, or a question.

In the past 2 years I have been on the site I don't think I have seen a single "bad" code-edit on an answer in the review queue. In almost every case it is people fixing the answers after they have tried to run the code and the code fails due to typos, copy/paste, or simple logic errors that the answerer made.

I have approved many suggested edits to my own posts that correct my numerous fat-figering (an unfortunate monkey side-effect).

###Solution

The solution is that code suggested edits, if they have an edit comment that makes logical/obvious sense, should just be approved. If there's a problem, well, the answerer who's code was edited will get a notification of the edit, and they can easily roll it back if it's wrong.

There is no need to set up a comment/response cycle that @amon has suggested. That's too slow, and requires humans to check things later, and is error prone.

The examples @amon shows are classic. The edit comment is:

Comment: Logic corrected on if loop. The previous logic is incorrect, after one generation all cells become dead because they are not counted properly. Now the cell isn't counted only if i AND j are equal to row_idx and idx. Before, when only one row_idx or ix was equal to i or j the cell was discarted.

To me, that is obvious that the editor has run the code, debugged it, and is has heart that is 2 sizes bigger and is contributing the efforts of his work back to the community. Give them the 2-rep points, make the site better, and approve the edit. It's the right thing to do. (Then, go and find some other good contributions they have on the site, a question, an answer, something, and if it is worthy, upvote it, so that they are closer to having the reputation where a review is no lonter needed!).