I am quite new to TEX.SE, and I'm doing my best to reply to the posts I can and help out. Recently I noticed some edits being rejected, some of which I may understand, but then there's others which I can't wrap my head around, like this one: https://tex.stackexchange.com/review/suggested-edits/166987

The reason provided makes it sound like vandalism (those who edit Wikipedia may have heard it as reason for reverting edits), but in my opinion if you look at the "rendered output", my edit makes it so much easier to read, also there were mistakes in the mwe which made it fail when compiling.

I'm trying to understand in order to improve my future edits according to community guidelines. Thanks for any clarification!

  • 3
    It does not take away from the rest of your point, but as far as I can see the MWE compiled in the unedited version as well. It was not necessary to comment out the *I've cut bits out* and remove the empty lines (though at least removing the empty lines makes the code easier to read).
    – moewe
    Mar 14, 2019 at 16:19

2 Answers 2


Disclaimer: This is purely speculative, only the reviewers will be able to tell why they rejected this edit

This is how the start of your suggested edit looks like in the (markdown view) of the review queue:

enter image description here

It clearly is not, but at the first glance this might actually look like vandalism to long time users, because the syntax of marking code blocks with ``` was only added a couple of weeks ago and before that the removal of the indention would have completly broken the rendering of the post (in fact many users might actually not yet know about the ```, because afaik there was no formal announcement about this new feature other than accidentally reading about it on main meta).

If this is indeed the reason for the rejection, this would also explain https://tex.stackexchange.com/review/suggested-edits/167032

Minor points which might have also influenced the decision:

  • Commenting out text in the MWE was not strictly necessary. Even if unrelated to the problem the additional text in the document body would not lead to a failure of the code

  • one might also argue that adding indentation to the tags and removing the formatting tag might not be the best course of action

  • Thanks, being new I didn't know about the code blocks being new. I'm used to having a certain character defining an "inline" code and 3x the char starting a block. Then I hope this post raises awareness among long time users, that it is in fact acceptable. Reviewers should imho anyway take at least a bit of time to review edits before accepting or rejecting them :) Mar 14, 2019 at 15:45
  • @Superuser27 True, reviews should be done carefully. Personally I'd be in favour of a stricter rate limit for reviews, for example only one review per minute. On the other hand keep in mind that such miss-judgements can be avoided if the edit focuses on the necessary changes - this avoids situations in which one has to judge a combination of useful, unnecessary or even incorrect changes. OK, in such a situation one could always use the "improve edit" or "reject and edit" button, but in reality it is often weighing the benefits of an edit against the downsides. Mar 14, 2019 at 16:16
  • 1
    Very good point about the indentation tag. I actually saw the edit in the review queue and decided to skip because I could see that the output image was modified (different link) and I did not remember to check the rendered output.
    – moewe
    Mar 14, 2019 at 16:21
  • 1
    @Superuser27 Oh and maybe I can pass along some conclusions I reached after being on this site for a while: don't take the outcome of review queues too seriously, they often lead to random results. Mar 14, 2019 at 16:27
  • @samcarter I honestly didn't know how the "indentation" way of formatting as code works so to be sure I always put it between opening and closing tags when editing :) but I'll be more careful to edit just "relevant" bits in the future! Mar 14, 2019 at 16:29
  • 2
    @Superuser27 Just to make sure you don't misunderstand my post, I don't blame you in any way for not knowing about the code block indention, I just wanted to point out a potential point for misunderstanding. And it is great that you ask about things like why your edits have been rejected! Mar 14, 2019 at 16:50
  • @samcarter thanks for clarifying, I appreciate all the support! I just wish there was an option for reviewers to leave more specific comments as to why an edit was rejected (more specific than the "standard" texts anyway), so people can learn and grow from their mistakes Mar 14, 2019 at 20:01
  • 1
    The edit you linked to shows another kind of change (@Superuser27): The edit does remove the item indentation from the code blocks (see rendered output). That may not be what is considered useful because the code clearly belongs to the items (one could argue it makes the post harder to read).
    – TeXnician
    Mar 16, 2019 at 9:51
  • Did you have a look at the rendered output @TeXnician? Because I think you're missing the point of this conversation, which is exactly the fact that people may think I removed the code formatting. Mar 17, 2019 at 9:11
  • 2
    @Superuser27 Have a look at the rendered output of tex.stackexchange.com/review/suggested-edits/167032 With your code formatting the indention of the rendered code blocks is lost. With your edit they are indented the same way as code blocks outside of an itemisation would be, before that they were indented twice, once for the code block and once to have the same indention as the surrounding list. Mar 17, 2019 at 11:45
  • 2
    @Superuser27 I tried to illustrate the change in this quick sketch i.stack.imgur.com/dG8KH.png Notice the position of the red square in relation to the code block Mar 17, 2019 at 11:51
  • 2
    @Superuser27 Not a problem at all, just a tiny advice: Having file names such as thesis.tex marked as in-line code is common practise on this site, so removing it might also look unnecessary Mar 17, 2019 at 11:55

TeX.SX is not considered to be a forum but people can post questions and answers. Today, and especially in such sites that many people are living a big part of their life online helping other people (or not), each one of such users have an online identity connected with their nickname (and some times with their real identity out there).

People who spend so much time online being active users with posts and comments etc (and not just reading posts or just been logged in), is at least simple logic that they are interested a little bit or more about this online ID.

So, changing many things on a post, is always a risk to make unwanted changes from the original poster. For example a rephrase of a sentence could improve its English grammatically but also could be using such a formal language that the original poster would feel sick about owning that post. (Just an example to make clear how careful we should be on editing and not just reformatting a post).

This is my general opinion and it is not specific to the linked rejected changes.

About the linked rejected changes, on the "language" changes, I already gave a reason above but it is not specific to your post since I already read it three or more times to understand it and try to find if there is an improvement on it (not good enough English -I mean my English-).

So, my final answer is that we should be really careful with changing something more than the format of a post without being absolutely sure that this edit is not just improving the question/answer but is also acceptable by the author.

Personally I would have skipped this edit because of the "language" changes and would have leave it to the others to accept or reject.

You must log in to answer this question.

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