Timeline for Add info to the help center stating what not to edit
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 3, 2020 at 13:30 | history | edited | CommunityBot |
Commonmark migration
|
|
| Jul 27, 2013 at 9:01 | comment | added | Bart | There are always cases which will fall outside of the general rules. And heck, I've made edits that would be advised against. (One character edit anyone?). The problem in giving leeway is that I fear users will only see what they are allowed to do. Some of the general interpretations that come up here regarding tool recommendations for example are a direct outflow of a fairly innocuous statement on programming tools in the Help Center. Code edits are tricky. Reviews are not always great. I'd rather say "no" and have them understand "but" as they mature on the site than say "yes, carefully". | |
| Jul 27, 2013 at 8:56 | history | edited | Mark Amery | CC BY-SA 3.0 |
added 615 characters in body
|
| Jul 27, 2013 at 8:55 | comment | added | Mark Amery | @Bart If the code can't obviously be fixed by a trivial correction that makes it exhibit the problem being asked about, then you we're agreed that you shouldn't edit. (You should probably downvote, and comment if nobody else has already.) What I don't understand is why you feel the need to generalize from that that any and all behavior-changing code edits are harmful, when it seems to me that there are cases (like those I described) where they are obviously helpful and the concerns you've raised don't apply. | |
| Jul 27, 2013 at 8:50 | comment | added | Bart | Because your edits will not necessarily reflect the situation at hand for the OP. There are tons of C++ examples where the OP says "This is what happens" and the comments are "No, because that won't even compile". I can correct those to something that will exhibit a similar problem, but there is no guarantee it reflects the OP's exact situation. Especially given the often vague descriptions. Have them correct it and show it to us. Then we're on the same page. Are there scenarios where it's an obvious typo? Sure. But there are plenty where this is not the case. | |
| Jul 27, 2013 at 8:46 | comment | added | Mark Amery | @Bart Sure, they should. Heck, they should have posted code that properly exhibited the problem originally. But they didn't, and now the issue exists, and it's probably easier to just edit it than to point out the problem to the author and ask them to fix it. Almost all edits are about fixing things the author has done wrong; I don't understand why you object to editing in the particular case described. | |
| Jul 27, 2013 at 8:43 | comment | added | Bart | "It's easily fixable, and it looks like the mistake was probably introduced by the author either when anonymizing their original code or creating a minimal demo case without testing it as thoroughly as they should've." ... then they should go back and show us their actual code, or produce an actual sample which exhibits the problems stated. | |
| Jul 27, 2013 at 8:41 | comment | added | Bart | Then add a minor "when they might be the cause of the problem" to the Python section. I don't really care about the wording. | |
| Jul 27, 2013 at 8:39 | history | answered | Mark Amery | CC BY-SA 3.0 |