Timeline for Add info to the help center stating what not to edit
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 20, 2017 at 10:30 | history | edited | CommunityBot |
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
|
|
| Apr 24, 2014 at 13:50 | history | edited | CommunityBot |
Migration of MSO links to MSE links
|
|
| Aug 12, 2013 at 14:41 | vote | accept | Bart | ||
| Jul 27, 2013 at 22:29 | comment | added | Bart | Not a euphemism no. :) But we've all seen the poor edits which arguably are for rep or badges and which aren't up to scratch. And which subsequently get through because the review process has its flaws as well. And with code, that gets iffy pretty fast. I guess we'll have to agree to disagree to some extent. You seem to have more faith in the system than I do, and you arguably have the data to back it up with. (Not that I'm claiming the sky is falling down though) But thanks for your input anyway. Always appreciated. :) | |
| Jul 27, 2013 at 22:02 | comment | added | Shog9 Mod | "Editors for editing sake" @Bart? Is that a euphemism for something? Anyway, the hard line would boil down to fundamentally changing the nature of the question - and sometimes, finding that line requires you to know something about what you're reading/editing. Does this make life harder for reviewers and provide fewer guarantees for those without full editing rights? Heck yeah! But remember, we do have a fairly sizable population of editors with full editing rights too. | |
| Jul 27, 2013 at 17:53 | comment | added | Bart | That's pretty shaky ground you're treading upon then. If you're answering, you might have a reasonable idea. But not all editors are answerers. Some are editors for editing sake. And where is the line? Code edits arguably require even more editing and reviewing expertise than formatting changes or even spelling corrections. Especially where they become non-trivial. And how do you deal with the situation where you essentially say "Sure, code edits are fine if they make proper corrections" yet the editors find them rejected by the community in some unwritten form of consensus? | |
| Jul 27, 2013 at 17:38 | comment | added | Shog9 Mod | Please refer to Mark's answer, @Bart. I've many times "fixed" typos in questions that were clearly describing a problem that had no connection to the error being fixed. Missing braces, semicolons, unescaped angle brackets, misspelled classnames... In particular, if you're answering the question it's probably fairly obvious to you what the problem isn't. | |
| Jul 27, 2013 at 17:35 | comment | added | Bart | I'm assuming you're purely referencing answer edits here @Shog9? If you want to encourage code improvements (which you might then have to inform the community about, because the consensus seems to be different) then at least let that go hand in hand with a better targeting of reviewers. That would leave the issue of editing code in questions. Or do you object to saying anything about that in the Help Center as well? | |
| Jul 27, 2013 at 16:39 | history | edited | Shog9Mod | CC BY-SA 3.0 |
added 1437 characters in body
|
| Jul 27, 2013 at 16:18 | comment | added | Shog9 Mod |
I've also seen a fair number of suggested edits that make questions easier to read and understand by fixing irrelevant errors, @Cody - as Mark notes in his answer, the guidance suggested here, though perhaps written with the best of intentions, explicitly warns against changes that are all but essential. If anything, we need better guidance (and canned reject reasons) for reviewers - if we're currently encouraging worthless formatting changes over helpful code-cleanup, then that's a much bigger problem.
|
|
| Jul 27, 2013 at 9:19 | comment | added | Cody Gray | I agree with 99% of this. My only concern is that I see a fair number of suggested edits that "fix" code in questions. Their edits are certainly correct from a compiler's perspective, but they're inappropriate because they obscure the question itself. Even if the edits are not to things fundamental to the question, good answers will often comment on other problems. The edits make those answers confusing nonsense. | |
| Jul 27, 2013 at 8:53 | comment | added | Bart | Heck @Shog9, you can even turn it around. Add it to the "When should I edit posts" section. Make it a "Tread with care" advice. You could give advice along similar lines, but perhaps that's a more positive and less excluding angle. But to say nothing is, IMO, not the way. | |
| Jul 27, 2013 at 8:39 | comment | added | Bart | @MarkAmery If there is a case of poorly copy-and-pasted Python code, in an answer, which is otherwise correct except for the indentation, I would have no problem with the edit. If we're talking about a question however, the indentation might be well part of the original problem. | |
| Jul 27, 2013 at 8:37 | comment | added | Bart | And breath.... should you be more careful when editing code in answers? Sure. Are users? Not really. (I know, I know, I should back this up with example edits and the like.) Should reviewers only accept them when they are correct? Sure. Will they? Not really. Feel free to reword my proposed text if parts of it offend you. It's a mere proposal. But if nothing even states that code edits are deemed problematic, we shouldn't be surprised they happen, that they happen poorly, and that we have Meta users wondering why they got rejected. | |
| Jul 27, 2013 at 8:15 | comment | added | Mark Amery | Agree completely. Not only is the general sentiment here against making any useful edits besides typo corrects and code formatting improvements, but it even explicitly discourages some of the most useful them (like cleaning up indentation in a poorly copied-and-pasted code block in a Python question). I don't know how to write good general guidance on when and how to edit, but I'm not a fan of Bart's attempt here. | |
| Jul 27, 2013 at 8:11 | history | answered | Shog9Mod | CC BY-SA 3.0 |