I am reminded of a cartoon I saw recently in a urologists office that said: "In this line of work, I see a lot of ass holes and pricks."
There is no shortage of people who are nasty, both among those who seek help and those who are able to give it, in any community. I would say, though, that instead of endorsing nastiness, for whatever reason, it ought to at least be ignored, and would be better repudiated. I can recall trying to teach elementary statistics to first year undergraduate students: and a particular subset that was terrified of math to begin with. They were under the mistaken belief that they could function without any quantitative capability. While I disabused them of that delusion right quick, I found I had to do that gently as they were so insecure that it would have been easy to crush their spirit to a point where they'd drop out of university altogether for lack of confidence. Instead of being harsh with them, I had to gently bring them around, in some cases giving them early on assignments that were mathematical but structured in such a way they didn't notice the mathematical nature of it until after the fact. Invariably, they succeeded in these assignments and i was able to tell them something like: "You see, you told me you couldn't do math, but look what you have done. This problem was inherently mathematical." THAT was a confidence builder. Had I taken the RTFM approach with those kids, the scientific community would have forever lost some bright minds long before they had begun to flourish. At that time, I found I also had to develop a skill in NOT laughing at questions that struck me funny. That happened frequently, simply because I was dealing with kids so new to quantitative analyses that many of the questions they asked were funny. But I dared not laugh because I knew these students asking such questions were so insecure that they'd have been crushed had I laughed. eventually, by the time I was finished with them, they had built their confidence levels and were also able to laugh at the question they'd asked initially, but it takes time to led a student to that point. I can remember, when I first used a unix system many, many, many years ago, I encountered a problem and was told by the department's system administrator to RTFM. This was a guy who was paid to help staff and students to use the department's computing resources. He was brilliant, but sorely lacking in interpersonal skills (except for when he had to deal with his supervisor). When I replied that I had, his response was that I must therefore be too stupid to deserve to use the computer system. I, however, am not the sort of individual that is so easily thwarted (I can't be insulted because I am too stupid to understand the insult! ;-), and eventually I became the "go to guy" when someone in my department had a computational problem. But often I found I had to take longer to figure things out on my own that I would have needed if I had access to someone who had both the expertise I sought to develop in myself and the spirit of a real educator. While it has been a while since I worked in an educational institution, I have found that generally when students or junior programmers came asking questions, it was MY fault. Either the documentation or verbal direction I'd provided was inadequate, or I had made assumptions about their background that led me to expect too much of them. Either they did not have the mathematical background I'd assumed, or they didn't have the knowledge of programming that I'd assumed. In many cases, these "kids" were so new to a particular issue or subject, they would not have been able to produce a useful query in Google if their life depended on it. They could try to submit a query, but the signal to noise ratio would be so low there'd be no hope they'd live long enough to find the signal. Part of the problem of this particular medium is that you never know who the person is that you are trying to help. So, then, the documentation provided to all, and help in this sort of medium, ought to be constructed not only with a view to helping peers use R, but also with a view to helping those just getting started. There is a lot of R documentation that seems to be written by experts for experts (which is fine as far as it goes), but at a level that is far to advanced (either in programming or in statistics) to be useful for beginners. Maybe that warrants two or more sets of documentation, some of which are intended for users with different levels of experience. There are a number of ways that can be handled. It is certain that the FAQs that exist are not nearly comprehensive or detailed enough for all levels of users. That said, the quality of documentation varies considrably among the different R packages I have examined, and I have found that I have tended to rely most on those packages that are best documented. A different part of the problem is time management. There is always too little time, but then, that is why people have to write useful documentation even when most of us hate writing that kind of documentation. And experience shows that documentation is never done, because questions asked about it generally highlights deficiencies in the documentation we've produced. I recognize that it is hard to write good documentation when a key step involves asking the question: "What does this presentation assume in the background of the reader?" Followed by the question, "How must it be changed if the reader's background is inadequate for him or her to understand the document as currently constructed?" But this must be done if one truly wants both to avoid answering similar questions time and again and to avoid driving away potential users/contributors. My thesis supervisor once told me I should try to write my thesis so that a fresh graduate from elementary school could understand it, and that if I did, I might produce something that a graduate from a liberal arts college may be able to understand, saying it was arrogant of me to assume my reader had skills comparable to my own. I know there are limits to how far you can take this. One can't address the infinite number of deficiencies that exist in elementary and secondary school education. But if one takes the time to nurture even those who ask questions that some find too basic to warrant a good answer, eventually those users will be both able and willing to help those who follow, lightening the burden of those who are involved in further development. And it gets more challenging as how do you write documentation for Bayesian analysis that is useful for someone who knows just about everything there is to know about nonmetric multidimensional scaling in ordination but so little about Bayesian analysis that he doesn't even know the right questions to ask? I hope you find these few reflections useful in your deliberations on constructing a useful policy in this matter. Cheers, Ted On Sat, Aug 21, 2010 at 6:40 AM, Spencer Graves < spencer.gra...@structuremonitoring.com> wrote: > Hello, All: > > > I think there is a logic to Gabor's perspective, especially regarding > unintended consequences. > > > For example, if the as a result of changing policy, our most creative > and substantive contributors decide to reduce their level of contribution > and are not effectively replaced by others, then it would be a great loss > for humanity. > > > This group, especially the R Core team and the R-devel community more > generally, has been incredibly productive. The result is a substantive > contribution to humanity. It would be a loss if any change reduced that. > However, if rudeness is driving away potential contributors as was claimed, > then this community might be more productive with a "no RTFM" policy. > > > I accept that the experience of the Ubuntu Forums and > LinuxQuestions.org may not be perfectly relevant to R, but I think they > could provide some insight: I would expect them to have some of the same > "rationing" problems as experienced on the R help lists. > > > The exchange that generated my original comment on this was a question > from "r.ookie" to R-Help. I don't know why this person chose to hide their > real identity, but I was subsequently informed off line that the RTFM > comment I saw was a response to an apparently rude reply by "r.ookie" to a > previous suggestion by a regular contributor. I still think a better > response is not to escalate: Either ignore the post or say something like, > "I don't understand your question. Please provide a self-contained minimal > example as suggested in the Posting Guide ... ." > > > Best Wishes, > Spencer > > > > On 8/21/2010 2:08 AM, Simone Giannerini wrote: > >> Dear Gabor, >> >> I do not agree with your claim >> >> "In the case of the R list there is a >> larger potential demand for free help than resources to answer and >> without the usual monetary economics to allocate resources I believe >> that the functional purpose of rudeness here is to ration those >> resources and minimize duplication of questions" >> >> In fact, apart from the fact that rudeness should never be justified, I >> was >> amazed at the amount of time dedicated by some people to give unhelpful >> replies to dumb (and less dumb) questions (at least on R-devel). In my >> opinion this behaviour causes some damages to the whole R project for at >> least two reasons: >> >> 1. On the bug report side if you want to have a good percentage of true >> positive reports you should allow for a high percentage of false positive >> reports. But if people are scared to post you will lose the true positive >> together with false ones. >> 2. People that are potentially willing to contribute are discouraged to do >> it. >> >> Kind regards >> >> Simone >> >> On Fri, Aug 20, 2010 at 8:37 PM, Gabor Grothendieck< >> ggrothendi...@gmail.com >> >>> wrote: >>> On Fri, Aug 20, 2010 at 2:12 PM, Paul Johnson<pauljoh...@gmail.com> >>> wrote: >>> >>>> On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves >>>> <spencer.gra...@structuremonitoring.com> wrote: >>>> >>>>> What do you think about adding a "No RTFM" policy to the R mailing >>>>> >>>> lists? >>> >>>> Per, "http://en.wikipedia.org/wiki/RTFM": >>>>> >>>>> I think this is a great suggestion. >>>> >>>> I notice the R mailing list already has a gesture in this direction: >>>> "Rudeness and ad hominem comments are not acceptable. Brevity is OK." >>>> >>>> But the people who behave badly don't care about policies like this >>>> and they will keep doing what they do. >>>> >>> Although it may seem hard to justify rudeness its often the case that >>> even the most bizarre behavior makes sense if you view it from the >>> perspective of that person. In the case of the R list there is a >>> larger potential demand for free help than resources to answer and >>> without the usual monetary economics to allocate resources I believe >>> that the functional purpose of rudeness here is to ration those >>> resources and minimize duplication of questions. If that is correct >>> one can predict that if civility were to become the norm on this list >>> then other rationing mechanisms would arise to replace it. >>> >>> For example, it might become the norm that most questions are not >>> answered or are answered less thoroughly or the list might be replaced >>> as the de facto goto medium for R questions by some other list or web >>> site so we have to be careful about unintended consequences. >>> >>> ______________________________________________ >>> R-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
