[R] draft of posting guide

[Duncan Murdoch]

On Sat, 20 Dec 2003 07:51:14 -0500 (EST), you wrote:

>2. I think "bug" needs to be taken in the broader
>sense of a problem.  Such problems are not limited
>to discrepancies between documentation and
>implementation.  The real serious problems are
>design problems and may not represent such
>deviations at all.  If the behavior is unexpected
>it may very well be a problem even if its not a
>bug in the narrow sense.

I agree that discussion of those things is good (probably better in
r-devel than in r-help).  However, this discussion shouldn't take
place in postings that are submitted as bug reports to r-bugs.  What a
lot of people don't seem to realize is that every posting to r-bugs
creates work for someone in the core group.  If you have some idea for
R that doesn't interest me, I can ignore it in r-help or r-devel, but
not in r-bugs.

The draft guide should be changed to mention this:

 If you're not completely and utterly sure
  something is a bug, post a question to r-help, not a bug
  report to r-devel.  

should be

 If you're not completely and utterly sure
  something is a bug, post a question to r-help or r-devel, not a bug
  report to r-bugs.  

>3. Rude answers are never warranted.

That's true, but needs expanding.  Rude questions aren't warranted
either, and not all apparently rude responses are really rude.

Better to say "Rudeness is never warranted, but don't take offense too
easily.  Sometimes RTFM *is* the appropriate response."

>4. Its too long and there are too many "rules".  

Which ones should be dropped?

>5. The tone should be friendlier -- more helpful
>and inviting.  Words like "lazy" should be
>eliminated.  

I thought "lazy" was used in a friendly and helpful way.  Which other
"words like" did you have in mind?

>Although R is not a commercial
>enterprise and its users are not customers in the
>usual sense, its users should still be treated
>with respect and encouraged rather than
>admonished.  

>A customer oriented attitude will
>be appreciated and encourage more participation.

I agree with the "respect and encourage" part, but not the rest.
You're thinking too much about a divide between users and developers.
You should be thinking of everyone as participants in the R project.
The participants in R-core have special access and can change the
source code, but all users are participants, and should be prepared to
be criticized when appropriate.  They *aren't* customers, and
shouldn't expect to be treated as customers.

>The purpose of this should not be so
>much to tell posters what they can do and not do
>but to help them elicit useful responses and
>to help responders provide userful answers.

The former does help with the latter.

>The real problem with the lists is not the
>posters.  The real problems are:

Everything on the lists comes from the posters.  There is nothing
else.

Duncan Murdoch