Timeline for Should users suggest technical edits?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 20, 2017 at 10:32 | history | edited | CommunityBot |
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
|
|
| Feb 21, 2017 at 23:50 | comment | added | TOOGAM | I agree. If something says C:\\file.txt then people should generally assume that subdirectories are double-slashed. Such an edit may be a bit more clear for some people, but makes the Edit history more cluttered. The answer, as provided, wasn't wrong in any way; a comment added below the answer would accomplish the same positive thing. | |
| Feb 19, 2017 at 13:55 | comment | added | Braiam | @GypsySpellweaver man, you will be a hell of a reviewer. That's actually what we look for. | |
| Feb 19, 2017 at 13:54 | comment | added | Braiam | @allquixotic "Perhaps if enough people feel the policy of "don't judge technical accuracy when editing" is problematic" actually, this culture is only prevalent on SO. Most sites don't agree with it (your answer here, on UL, Shog himself (I'm sure you can find examples elsewhere). But one of the policies of SE is that if someone can improve something, there's a button to do just so: edit. | |
| Feb 14, 2017 at 8:27 | comment | added | Chindraba | I haven't gotten into the review process yet, but since my rep is getting close I did look, once, at what's involved in the process. I seem to remember a mention of the idea that if you're not sure whether to accept or reject a review, just pass on it. Seems to me that if an edit involves a technical detail, and I don't feel qualified to judge it on its merits, I should pass, and allow someone more capable to handle it. If the editor also included comments on the edit page that clarifies why the technical edit is needed, it should help reviewers judge the accuracy if they know the subject. | |
| Feb 12, 2017 at 4:46 | comment | added | Ben N | @WBT The usual reason for rejecting technical changes is something along the lines of "deviates from the original intent of the post." In this particular instance, though, the reviewers probably objected to what they saw as the triviality of the change, so the used reason makes some sense. | |
| Feb 12, 2017 at 4:00 | comment | added | WBT | Could this be made into a rejection reason so that it's easier for people to understand this nonintuitive policy? The canned "This edit does not make the post even a little bit easier to read, easier to find, more accurate or more accessible. Changes are either completely superfluous or actively harm readability" does not seem to be a good fit for helping people learn about this rule. | |
| Feb 12, 2017 at 2:31 | comment | added | Ben N | @WBT Oops, I didn't notice that the "edit" text was a link, sorry. I've removed the duplicitous part of my answer. | |
| Feb 12, 2017 at 2:30 | history | edited | Ben N | CC BY-SA 3.0 |
deleted 106 characters in body
|
| Feb 12, 2017 at 0:04 | comment | added | WBT | See also: Edit to correct a basic path syntax error in an answer rejected - why? | |
| Feb 11, 2017 at 22:39 | comment | added | WBT | For what it's worth, I am familiar with the fact that many technical settings require escaping, but enclosure in quotes is a common way for such escaping to happen (and is how spaces are escaped here). As double slashes are needed after the protocol component of a URL, sometimes double backslashes are needed at the beginning of a file path following a drive letter or share. Also, I did include a direct link to the edit review in the question. | |
| Feb 11, 2017 at 22:07 | comment | added | allquixotic | I'm not sure we'd (ever) be able to succeed at changing this culture SE-wide, mind you, as there's a lot of momentum around the status quo on stackoverflow in particular; but the SU community is small enough and agile enough that we could enact meaningful change that helps the site if we had the willpower to push for it. :) | |
| Feb 11, 2017 at 22:06 | comment | added | allquixotic | Interesting discussion here, and even more interesting that you seem to feel this situation is "unfortunate" but "is the way it is", @BenN. If a policy is actively detrimental to the site, and you feel that way, why not also offer your opinion stating that fact? Perhaps if enough people feel the policy of "don't judge technical accuracy when editing" is problematic, and argue convincingly for the opposite, we might at least change some users' behavior, if not the official word from on-high as to best practice when reviewing edits. | |
| Feb 11, 2017 at 22:04 | comment | added | Ben N | @WBT As unfortunate as that situation is, yes; that is my understanding. On the bright side, once you have >2K reputation, you can fix it yourself because your edits won't have to be reviewed. | |
| Feb 11, 2017 at 22:03 | comment | added | WBT | "Strictly speaking, edit suggestions shouldn't attempt to change the technical details, since reviewers aren't expected to judge technical accuracy." Therefore, if there's a technical bug in the answer and I've gone through the effort to figure out how to fix it, I know now I should not be suggesting that edit to fix it. It will be up to later readers to figure that change out for themselves - and if I'm feeling like longer explanations, maybe they'll be able to find it buried in comments. Got it. (Not convinced this is the best answer, but thanks for answering.) | |
| Feb 11, 2017 at 21:51 | history | answered | Ben N | CC BY-SA 3.0 |