Giters

not-yet-awesome-rust / not-yet-awesome-rust

A curated list of Rust code and resources that do NOT exist yet, but would be beneficial to the Rust community.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

StackOverflow: many Q&As aren't very up-to-date!

ErichDonGubler opened this issue · comments

commented

Quote from @bheklilr on Reddit:

I don't know if this is something that really belongs on this list, but I will say that as a novice rust user I often run into the problem that stackoverflow Q&As/blog posts/etc are from 3 or 4 years ago and the solutions presented there are no longer valid with how much Rust has been updated. I'm not sure what the solution would be, but maybe it could involve putting together a task force to go through and provide updated answers to the most popular questions on SO, finding popular blogs and seeing about getting them updated/deprecated/rewritten, that sort of thing. This would be a lot of effort that wouldn't be terribly visible to people already in the community, but it would be a boon to newcomers. Rust's documentation is great, but it doesn't always have direct answers to a lot of questions asked by noobs like myself. There isn't as much community content, and unfortunately a lot of it is outdated to the point of not even being syntactically correct. This can definitely cause headaches for people trying to get started with Rust.

commented

My bet is that the most helpful thing to do with this is to compile the list of Q&As that are out-of-date. I'm more than happy to trawl through this -- but it might take me awhile, and I doubt I'll get everything!

commented

Instead of waiting to stumble across SO posts that are out of date, it should be pretty straightforward to query which ones are older a year old and just sort by most viewed. Someone with an hour or two could also help triage them by importance after that.

I think if anyone is going to get serious about it, that there should be an effort to post new answers in a set format that includes a statement about why there is a new answer and what compiler/lib versions the new answer targets.

I wonder if there is a way for someone with enough rep to edit old posts without needing the original author's approval so that disclaimers could be added to the top.

Alternatively, for each post a new one could be written using the community answer feature, then the old could be marked as a duplicate of the newer. This would help to direct traffic to the new questions while leaving the old ones untouched.

commented

@shepmaster, is there anyone (maybe like yourself?) that has enough rep to do something like @bheklilr suggests?

@bheklilr, maybe you could get that query together and we could get a checklist going? :)

commented

Sure thing. I'll try to figure that out tomorrow.

commented

I believe creating a little browser extension for marking outdated content as a community effort would be worthwhile.

Of course everyone interested in using the extension would have to hear about it and install it.

commented

Put the query together here, and I've attached the resulting CSV file here as well (although it's .txt because github won't allow .csv for some reason).

commented

I made a histogram by ViewCount with 20 bins and got

hist_20_by_viewcount

This shows that the majority of questions have very few views, but there is a long tail of posts with high view counts. We could definitely focus on those first. If I drop off the bottom 75% based on view count (below 1062 views) the histogram is

hist_20_by_viewcount_top_25pct

This still includes 860 posts, but I'm sure a lot of them already have up to date answers. Looking at them a bit more, there are actually 2 that don't have answers, but both were closed as off topic or opinion based.

Comparing this top 25% data set to the original, I decided to make a scatter plot of Score vs ViewCount, coloring the top-25% of viewed questions red:

scatter_score_vs_viewcount_top25

This tells me that there are a small number of highly viewed, high score posts. It would probably be easiest to target these first, as they would probably be most likely to be correct.

I'm going to kind of arbitrarily say based on that graph that any posts with at least 10000 views or 25 points should be investigated first. That drops the list down to 89 posts, much more manageable for someone to start going through. I'll post those URLs in a table in another comment once I get it generated.

commented
commented

Feel free to ping me here as needed, as I have enough rep for the edits.

commented

Also feel free to ping me; I have plenty of rep to do edits.

commented

I've updated the accepted answer on the first question on that list that had a substantially out of date accepted answer (from Rust 0.4!), How to Read User Input in Rust? (Id: 13579266, Views: 20824, Score: 30).

The answers before that all looked OK to me (Id: 3210025, Views: 6170, Score: 44, Id: 9271970, Views: 15293, Score: 20, Id: 13212212, Views: 10872, Score: 6); either had up-to-date code, or were just conceptual questions about older features (like typestate) which were clearly marked as being out of date and had no real associated code, so can probably be checked off.

commented

@lambda (and anyone else interested), if you comment here on which ones you've updated I'll check them off the list. Also, does anyone know a better way to set up that list so more people than me can cross off items?

commented

OK, I'll chime in. @lambda's edit was a bad one. There's already an answer with 121 upvotes and now the (poorly) accepted answer "steals" all the credit. Yes, Stack Overflow has issues, but that type of edit is breaking the community. If you want to do such a thing, just edit a link into the better answer edit a warning about oldness.

commented

@shepmaster Do you think (as someone with significantly more Rust experience and rep on SO) that we should have a sort of "review process" before these posts get edited? I certainly don't want there to be an effort to update all these out of date Q&As to turn into a sour point in the community. It would be a lot more tedious to do, for sure, but having at least one other person checking the work we should be able to avoid pretty much every situation where a bad edit is made.

commented

I'm sorry I didn't respond earlier; I didn't expect there to be action taken so quickly after the post last night.

Apologies for incoming wall-of-text.

we should have a sort of "review process"

I read and possibly edit every question and answer that gets created or updated (with the exception of when I'm on vacation, and even then I still check sometimes). At the very least, that's one review.

I also review every time one of my posts gets up/downvoted or when I link to a post.

before these posts get edited

That's trickier. There's no great process within SO for such a thing, so it would need to be external.

a sour point in the community

SO denizens (myself included) are a tricky, non-homogenous bunch. Even editing many Q&A in a short time period makes some people irate (as it pushes them to the top of the updated list).

That's not to say that there aren't things we cannot do better. We've been worried about this since Rust 1.0.

Instead of waiting to stumble across SO posts that are out of date, it should be pretty straightforward to query which ones are older a year old and just sort by most viewed. Someone with an hour or two could also help triage them by importance after that.

Yes, I think this is a good idea.

I think if anyone is going to get serious about it, that there should be an effort to post new answers in a set format that includes a statement about why there is a new answer and what compiler/lib versions the new answer targets.

Maybe. There are certain questions/answers that use e.g. ~ instead of Box / Vec and can be updated trivially.

Alternatively, for each post a new one could be written using the community answer feature, then the old could be marked as a duplicate of the newer. This would help to direct traffic to the new questions while leaving the old ones untouched.

This is again a contentious topic. Doing something like this "steals" the reputation gains that the old questions / answers would have had. For better or worse, rep drives SO, and messing with that will get people angry.

I wonder if there is a way for someone with enough rep to edit old posts without needing the original author's approval so that disclaimers could be added to the top.

This is a very safe thing to do, but I'd include why it's not just old but invalid. For example, if a new method is added to the standard library, that doesn't invalidate old answers, it just might mean a newer one is more idiomatic. That's what up- and down-voting are for.

commented

How to Read User Input in Rust? is a great example of something that bugs me. Yes, the accepted answer is old and not relevant, but why do we need to cater for the people that won't scroll down a half of a page. Dealing with accepted vs upvoted is a perennial topic on SO meta, FWIW.

commented

Another thing is that edits should be comprehensive. Questions and answers should be updated for modern style (I just rustfmt everything), grammar should be addressed, formatting should be corrected, links validated, technical accuracy should be checked, compiler error messages updated...

Except when that's the point of the question.

commented

so more people than me can cross off items?

You have to grant permissions to edit issues to check off items, sadly.

commented

Then there are things like How do I make an HTTP request from Rust? which shouldn't have been in Stack Overflow to start with (for exactly the reason this issue exists!):

Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam.

commented

Now, I swear that I'm not as much of a jerk as I'm very likely coming off as. 😇

commented

I often run into the problem that stackoverflow Q&As/blog posts/etc are from 3 or 4 years ago and the solutions presented there are no longer valid with how much Rust has been updated.

Perhaps you can tailor your SEDE query to find questions / answers last updated before Rust 1.0 was released. That's what will find "incorrect" or "invalid" posts.

commented

Dealing with accepted vs upvoted is a perennial topic on SO meta, FWIW.

And sometimes the upvoted answer is at the top. I've never figured out how or why.

commented

@shepmaster You weren't kidding about that wall of text lol

Now, I swear that I'm not as much of a jerk as I'm likely coming off as.

No worries mate. My worry is whether people (i.e. me) can google a problem with rust and find a stackoverflow post that actually works. I've somehow now been roped into this and have no idea what I'm doing, but at least I feel like I'm contributing in some way.

Perhaps you can tailor your SEDE query to find questions / answers last updated before Rust 1.0 was released. That's what will find "incorrect" or "invalid" posts.

I looked at the release date of Rust 1.0 and rounded up to the next year. 1.0 was released on 2015/05/15, so I figured that by lazily grabbing all posts created for a while after that too would capture questions by people who hadn't yet updated to Rust 1.0.

My initial analysis above was an attempt to find the posts that were highly visible without much attention to the creation date after that, simply because it was easy. Tonight after I'm home from work I should have some more time to devote to preening out the posts that are most likely to be updated. Maybe I'll try to come up with a ranking system based on creation time, last edit time, view count, and score, where this rank would give some rough estimate of how likely it is to be "broken" under modern Rust.

FWIW I never intended anyone to jump so quickly into trying to fix these posts. I was just trying to put together a manageable list of posts to start triaging. I personally would be more comfortable with at least a few of us agreeing on a plan of attack, but I'm also not someone with a lot of influence in the Rust community so I'm also susceptible to following someone else's lead on this.

commented

My worry is whether people (i.e. me) can google a problem with rust and find a stackoverflow post that actually works

Yeah, and I agree that that's an ideal end state. I just don't think that we can expect for people to turn off their brain, click on the first search result and end up with working code. If an answer is wrong, we should downvote it. If an answer is only valid for pre-Rust 1.0 that seems like a reasonable thing to warn about with an edit.

If an answer is just no longer "the best", a comment on that answer pointing at the new hotness (and maybe a comment on the original question) is probably the best bet. Having clear version numbers ("this answer was created when Rust 1.xx was most recent") can also help.

Remember that some people have to use old versions of Rust (IIRC, Debian packages Rust ~1.8 or something). We don't want to remove these answers from history.

but I'm also not someone with a lot of influence in the Rust community so I'm also susceptible to following someone else's lead on this.

Nah, that's not how it works ;-) Everyone has valuable input to provide. Some people may have more experience in one realm, but that doesn't mean other viewpoints are invalid.

For example, I don't remember the last time I've ever found an outdated SO Rust question — they don't even pass into conscious thought often. However, I've heard the "the solutions presented there are no longer valid" but very rarely have I ever had someone show me the Q&A.

commented

@bheklilr

Also, does anyone know a better way to set up that list so more people than me can cross off items?

Maybe just something like HackMD? I just copied your list in this document. I set it to "editable by logged in users", which I thought is the best option (you can login via GitHub). But this is just one idea.

Also: I have enough rep to help, too.

commented

And for transparency, we have a chat room on Stack Overflow and I've linked this issue there.

commented

@shepmaster

If an answer is only valid for pre-Rust 1.0 that seems like a reasonable thing to warn about with an edit.

I definitely agree. I don't want to remove valid answers for old versions of Rust, but I want to make sure that some of these questions get appropriate new answers with disclaimers.

Having clear version numbers ("this answer was created when Rust 1.xx was most recent") can also help.

Please? That would be fantastic.

Nah, that's not how it works ;-) Everyone has valuable input to provide. Some people may have more experience in one realm, but that doesn't mean other viewpoints are invalid.

I'm just being honest. A few years ago I had been a top contributor under the Haskell tag but eventually tapered off with my answers over there. I'm pretty familiar with SO and it's shortcomings, but now that I'm trying to come into the Rust ecosystem I keep occasionally hitting snags with this sort of thing. That's not to say that it's the biggest problem Rust is facing, and by far it is not, just something that I've run into enough to notice that it's a problem. I see you've been saying that it's been a while since you've seen an outdated SO post. I know I ran across one the other night, but it was on my home computer. I should be able to drag it out of my browser history later tonight as one that either I don't understand or needs updating.

commented

@shepmaster I strongly disagree with your opinion on my edit.

The issue here is with the way Stack Overflow is implemented; no one but the original questioner can change the accepted answer or cause another answer to float to the top.

The whole purpose of Stack Overflow was to solve the problem of forum posts about technical issues in which the forum structure made it hard to find the correct answer. One such issue was when there was some bad answer early on, and then you had to find the right answer buried somewhere deep in the thread that was impossible to find.

But the current structure of Stack Overflow replicates that exact issue if there's an accepted answer, and both the question author and the answer author have stopped using Stack Overflow. Luckily, Stack Overflow allows edits; so you can edit the initial answer to provide an updated one. This is explicitly mentioned in the original Stack Overflow announcement: "You can also improve on the answers. If an answer is incomplete, expand on it. If an answer has a bug in it or is obsolete, you can edit it and fix it."

Somewhere in the intervening time, the culture at Stack Overflow seems to have become protective of content. Your reasoning, that we should refer to a lower down answer rather than editing the accepted answer in which the questioner and answerer seem to have no interest in updating it, is prioritizing some internet points for a few SO contributors over actual usefulness to the majority of people who come in and stop reading after the first answer.

Just leaving a warning is far less useful to casual people who drop by that answer than actually putting a real answer in that space.

commented

And sometimes the upvoted answer is at the top. I've never figured out how or why.

That happens when someone answers their own question. Accepted answers only go to the top if someone else answered them.

commented

@shepmaster I strongly disagree with your opinion on my edit.

I know :-)

Somewhere in the intervening time, the culture at Stack Overflow seems to have become protective of content.

And therein lies the rub; the Stack Overflow of 2018 isn't the Stack Overflow of 2008. The community has changed in drastic ways (and continues to do so). I made my comments here and the corresponding rollback based on my understanding of today's Stack Overflow community norms.

Perhaps people that share your same views that SO has gone off-track will do to SO what SO did to Experts Exchange. Maybe Rust should stop using Stack Overflow for such content.

However, it's important to note that we are playing in Stack Overflow's sandbox; we need to follow the rules.

Because I'm OK with the hivemind, I'd be more than happy to have you bring up the rollback to SO meta to get that feedback.

prioritizing some internet points for a few SO contributors over actual usefulness to the majority of people who come in and stop reading after the first answer.

Yes, it is.

However, I look at it as prioritizing the people behind the answers. The gamification of SO is nothing new, and internet points is the method that SO has chosen to encourage people to provide good answers.

You and I both have more reputation than we need at this point, but that doesn't mean that's not why other people answer questions. It's one reason I started answering questions on SO.

By essentially copy-pasting subsequent answers to the top spot, you unilaterally make a value judgement that one answer is better than another, removing the ability for the second, better answerer to "profit" from their hard work.

Just leaving a warning is far less useful to casual people who drop by that answer than actually putting a real answer in that space.

I agree, but I'm cold-hearted and not overly concerned with the users who cannot be bothered to scroll down a tiny bit.

commented

How to Read User Input in Rust? is a great example of something that bugs me. Yes, the accepted answer is old and not relevant, but why do we need to cater for the people that won't scroll down a half of a page. Dealing with accepted vs upvoted is a perennial topic on SO meta, FWIW.

Because who else are we catering for? Stack Overflow is about catering for people who want to do a Google search and find a quick answer without having to wade through a whole bunch of bad ones.

The top post, and big green checkmark, distinguish an accepted answer a lot more than the number of votes do.

I have paired with very sharp engineers who are quite impatient, so will Google for something that is confusing them and not well documented (or they're not sure where to look in the docs, or the like), open the top few links in tabs, and scan through each quite quickly and close it out if it doesn't look like it contains what they need. I've sometimes had to stop them and have them scroll back through one of the answers they went through because it looked like a later answer might actually have a better solution.

For someone like that, if I were to Google for How to Read User Input in Rust? (the name of the original question), I get one result from the forum in which the first answer is to use a crate, the next is some poorly formated non-idiomatic code, and some discussion of how this is kind of painful right now, the next is a link to std::io::Stdin which is not really a great starting point, and then we get this SO question which now has a big warning on top that it's no longer relevant for Rust 1.0. Someone who is fairly new to Rust might wind up pretty discouraged by these results.

By essentially copy-pasting subsequent answers to the top spot, you unilaterally make a value judgement that one answer is better than another, removing the ability for the second, better answerer to "profit" from their hard work.

I did no such thing. If you read my edit, it was entirely original; it followed the example in the question more closely than the top-voted answer, and provided both an idiomatic Rust version and a version that more closely mirrors the C++ version in the question.

I considered just pasting the top-voted answer in, and then decided not to for exactly the reason you cite.

By writing an entirely new answer, I'm just giving up some extra rep that I don't really need, and answering the question in a way can be compared more easily to the C++ version in the question.

I agree, but I'm cold-hearted and not overly concerned with the users who cannot be bothered to scroll down a tiny bit.

I disagree with this for two reason. One, I am less cold-hearted; one thing that has pushed me away from the SO community is how cold-hearted it has become. I really hate when perfectly reasonable questions get closed just because the person asking the question doesn't have the best grasp of English or doesn't know enough to describe their problem correctly the first time, even if it gets clarified in the comments. I must admit, part of this is just being frustrated at having wasted time and not being able to post an answer, since sometimes I've spent the time to clarify the question in comments, and written up an answer, and by the time I post it's closed, and then not enough people are paying attention to re-open. But part of this is simply that I am a lot more accommodating because I know how frustrating it can be to be a newb who doesn't know enough to know how to ask the right question, and then being flamed to a crisp for it.

And the other is that making SO really great for lazy people helps me out in the real world, because sometimes the person who wrote code I have to maintain is a lazy person who just read the first answer, or sometimes a coworker is lazy and so missed the right answer and now has to come bother me, or heck, sometimes I'm just in a hurry and working in a domain I don't know well and trying to navigate it through reading SO answers, and the fewer bad ones I have to wade through the quicker I can solve my problem.

Because I'm OK with the hivemind, I'd be more than happy to have you bring up the rollback to SO meta to get that feedback.

You're right, this discussion is probably more appropriate for SO meta, but I've gotten pretty burnt-out on discussions like this on SO meta before, because it seems that the majority of people on SO meta seem to share similar views; that it's OK to turn away newbies and drive-by Google users because they ought to have spent more effort asking their question or finding their answer.

commented

Coming back with some SO posts from my browser history:

These were the handful that I could find from recent browsing. To be fair, I think that @shepmaster has a valid point that this is less a problem than it seems and has gotten a lot better (with many thanks to the master himself). However, I haven't exactly been a prolific Rust programmer in the last 6 months, and my Firefox history does not extend beyond that (think I had a reformat around that time).

Looking at what I was able to find myself, I think I'm going to bias my analysis of rust posts to those that were created and last modified before 1.0. I think I can come up with some criteria based on view count, score, and last modified date to figure out which should be looked at first. I think the bigger risk might be those posts that are really close to the 1.0 line, but still a few months out from the release. Those are what I would consider "high risk" posts. These would be ones that have the potential for being subtly broken but with the highest visibility. Since search engines should prefer more recent posts in searches, I think it's safe to save the very old posts for later on, if at all.

commented

Anyone who thinks it's OK to keep content out of date just to maintain "integrity" is clearly out of their mind and not worth paying attention to. The clean-up tag on Meta SO is made for this. I'm sure there are many high reputation users on SO who are willing to help with editing the posts into a format that works for them. So yes, I think this discussion should be on SO meta, it would also help get eyes on the issue and spread out the work.

commented

@lambda Sorry, your edit break rules of stackoverflow:

clearly conflicts with author's intent
This edit deviates from the original intent of the post. Even edits that must make drastic changes should strive to preserve the goals of the post's owner.

If you want make your own answer you can, if you want make a community answer you can, but you can't edit the answer of someone else to "fix" it. If the answer is wrong, downvote it, don't edit it.

commented

I'm afraid I don't have much to contribute to the meat of the discussion here, since I'm trying to wrangle contributions elsewhere, but I just wanted to take a second and thank @bheklilr, @shepmaster, and @lambda for taking so much time to handle this issue. There are definitely differences of opinion, but I feel like everybody is trying to figure out how to improve things, and that the communication so far has been clear.

You guys are awesome! :)

commented

Is there any reason I shouldn't close this issue? There's been no new discussion, and it should always be accessible from the main list via link.

commented

I can say that nbro has been doing some good edits on some older questions. I'm not sure if they are reading this issue or not, though!

I think the roughest part about using the issue is that we can't jointly modify the list to "work through" things. The suggestion earlier is probably a better place for that type of work to proceed.

commented

@shepmaster: So, just to clarify -- is there an existing HackMD document you're suggesting this issue continue on (to facilitate collab), or are you saying it would be beneficial to make one? If it's the latter, I'm willing to compile everything I see from this discussion here in a new one.

commented

I'm going to declare a final comment period on this, since it seems a community exists around this issue. I'd like to give readers a resource to go to when they want to contribute to Rust's SO presence -- what from this discussion would be best?

commented

I still haven't gotten any feedback on this, so I'll close this issue for now. If somebody has a link to a HackMD document like what was previously discussed, or wants to create one, I'm more than happy to help. As always, holler if there's something else on your mind here or open another issue!

commented

@ErichDonGubler I did post a HackMD link in my first comment already. Namely this one: https://hackmd.io/CYFgbGCmCcCsDsBaMIBmJEgIZsQI0gCYAGRWARlVQGZYt5JhJqg=

But this was just the list from above, nothing special. Just wanted to make that clear. Although the initial motivation seems to have died down a bit in this thread :P

commented

Not sure if this is the right place to ask/comment, but I've been thinking about this issue...

I am just getting into learning Rust. Answers on StackOverflow being out-of-date is a real issue, as it makes me that more anxious to learn this language. Although I love the idea behind this repository, I think it is not the right place for this topic.

The repo is not-yet-awesome-rust, not "no-longer-awesome-rust".

The list provided by @bheklilr is awesome, but there doesn't seem to be any plan of attack.

So I was thinking, wouldn't it make sense to create a separate Gtihub repo for this?

We could make one issue per SO Question and have any discussions/code reviews there. This would also allow tagging items per topic (and knowledge level needed), making it easier to pick up issues to bring up to date.

Or, if (ab)using GH issues feels like the wrong vehicle, create a file per Question/Answer and suggest improvements through pull-requests. Once such changes get approved (or merged?) anyone with enough rep can update the answer(s) in question even if they might not have sufficient Rust expertise (like myself).

Or we could do both... Create a file and corresponding issue for each SO entry.

If there is motivation for this, I would propose creating such a repo and moving further discussion(s) there to iron out the details.

So, what do folks think? I don't mind taking on some organisational responsibilitites for this (as I already have experiecne do similar work for other FOSS projects).

commented

Answers on StackOverflow being out-of-date is a real issue, as it makes it makes me that more anxious to learn this language

What makes Rust any different from other languages? I (with my extreme bias) actually think that Rust has the most actively updated content of the Q&A I see in my "real work". Does Python or Ruby or JS or ... not have out-of-date content?

Why do you believe that a specific Q&A is outdated? Recall that Rust has strong stability guarantees, and something that worked 5 years ago will likely still work. This isn't to discount that crates may release semver-incompatible versions, or new language features may be introduced.

My worry is that basically people want to see a timestamp at the top of a Q/A that says "someone looked at this and it's still valid". Nowadays, that's effectively looking for the last upvote (you do upvote when you follow an answer and it works, right?)

I would propose creating such a repo and moving further discussion(s) there to iron out the details.

I've no objections, but I also wouldn't be surprised if it boiled down to a vast majority of "no, those Q&A are still correct". I'm willing to participate.

In the far future, perhaps the repo would also become a curated list of common / useful Q&A. Then you can figure out how to grab the code from the answers and run them on an automated schedule to ensure they are always correct (and feel my extreme pain when people refuse to provide minimal runnable examples).

commented

I also wouldn't mind a repository as a mean to quickly report out-of-date questions to experienced Rust StackOverflow users. I would certainly subscribe to the repository and fix these Q&As whenever I can.

I also agree with @shepmaster: from my experience, there aren't that many outdated Rust Q&As on SO. Anytime I encounter one, I fix it. And that hasn't happened too often, especially in the last 2 years or so. But sure: the problems I search for are probably vastly different from the problems beginners might have. So I'd be interested in what outdated posts beginners regularly encounter. I would be very curious how many of those Q&As are actually outdated.

commented

I also wouldn't mind a repository as a mean to quickly report out-of-date questions to experienced Rust StackOverflow users. I would certainly subscribe to the repository and fix these Q&As whenever I can.

As I understand it, this is not actually how StackOverflow works? See e.g. https://stackoverflow.com/review/suggested-edits/18904781 which was rejected for updating an answer from serde 0.9 to serde 1.0 because it should have been a new answer. Posting a new answer doesn't require reputation.

commented

@dtolnay That's a strange review and I would certainly disagree with the decision. Note that none of the three users who reviewed your edit suggestions ever posted any question or answer with the [rust] tag. So they had likely no idea what the edit was about. That's a huge disadvantage of the global review queue, but I guess that's another story.

Yes, editing question is a tricky business as you don't want to completely change the intend of the original author. But the kind of edit your linked is clearly just an update and an improvement.

commented

I'm not sure this was a glitch of the global review queue. As far as I have seen, Meta is extremely consistent about saying this type of update should be rejected and be a new answer.

We might disagree with this, but the bottom line seems to be:

Suggested edits which introduce new versions of code into an answer should be rejected as they should be fully fledged answers.

by putting a new version answer into the answer, suddenly this unverified and untested code appears to have received N upvotes from the community. As an editor or reviewer, I don't think 1 user's claim that some code works great is good enough to merit the unintentional support of N people who already supported the existing code

So the fact that top answers are quite often out of date for a fast-moving language and library ecosystem like Rust is in large part by design, sadly.

commented

@dtolnay Interesting. Thanks for bringing this to my attention. I hardly read meta and hardly make non-[rust] posts on StackOverflow. So this is just from my experience of edits in the [rust] tag.

FWIW, I often edit my own answers in much the same way. If I notice one of my answers being outdated, I completely edit it such that new users always see the most idiomatic and useful answer.

commented

I also wouldn't mind a repository as a mean to quickly report out-of-date questions to experienced Rust StackOverflow users. I would certainly subscribe to the repository and fix these Q&As whenever I can.

As I understand it, this is not actually how StackOverflow works? See e.g. https://stackoverflow.com/review/suggested-edits/18904781 which was rejected for updating an answer from serde 0.9 to serde 1.0 because it should have been a new answer. Posting a new answer doesn't require reputation.

The code is compiling with serde 1.0 and serde_derive 1.0, please check your facts. Damm I didn't look at the date. Yes, you should have do a new answer - -

You really did propose the edit twice to force it - -²

I mean there is a lot of way to handle it, but don't remove thing, just add !

commented

I would certainly subscribe to the repository and fix these Q&As whenever I can.

As I understand it, this is not actually how StackOverflow works?

"Fixing" it can mean to provide a new answer or edit an existing one.

My personal opinion on the "edit" vs "new answer" comes down to how big the changes are, which does rely a bit on subjective factors. For that serde question, the changes were minimal and I agree the edit should have been made (and you can see it was, and I have made numerous small changes to it since).

I do think these types of subjective questions can be discussed in any such repository (as we already do somewhat in the SO chat).