Someone on TECHWR-L posted a link to this paper (under the paradoxical title "The Cupertino Effect"), which is about how Excel's autocorrect feature can corrupt statistical analysis of genetic data if/when Excel "makes the wrong assumption" about an entry based on how it looks:
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
I've seen far too much of the attitude around that programmers should write the documentation, because the programmers know the application best (as if that's a particularly good criterion by which to create documentation!), and IME that really only accomplishes two things: It makes your programmers (who'd rather be programming, quelle surprise) cranky, and it pisses off your user base, when the documentation reads like something that has been hacked together by someone who doesn't know the first thing or care a whit about documentation. Brilliant.
Now, if someone were serious about getting technical writing students involved in F/OSS projects, I'd recommend contacting these folks: Cooperative Education and Career Services at the University of Waterloo, and the Rhetoric and Professional Writing and Rhetoric and Communication Design programme people. They do co-ops at both the graduate and undergraduate levels in those programmes, and, at least when I was there, seem to be quite open to unconventional project ideas...