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.graves@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<
>> ggrothendieck@gmail.com
>>
>>> wrote:
>>> On Fri, Aug 20, 2010 at 2:12 PM, Paul Johnson<pauljohn32@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Aug 19, 2010 at 7:08 PM, Spencer Graves
>>>> <spencer.graves@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]]

