Berwin A Turlach wrote:
>
>> i am sending *no* patch for this. the issue has to be first discussed
>> on the design level, and only then, if accepted, should anyone -- me,
>> for example -- make an attempt to implement it. tell me you want to
>> listen to what i have to say, and we can discuss.
>>
>
> I could tell you that I will listen and we can discuss this until the
> cows come home. This will not change one iota since neither of us have
> the power to implement changes in R. You keep barking up the wrong
> tree.
>
i am barking on the list; whoever is the appropriate person to react,
has the chance to read and react. i don't think it's appropriate to
send my messages to x or y personally. what is the right tree, you say?
> So far I have seen only one posting of an R-core member in this thread
> (but perhaps he has started further discussion on the R-core mailing
> list to which we are not privy), but if you want to have discussion and
> acceptance before you do anything, you have to get R core involved.
>
> Since for the kind of work for which I am using R a facility for
> sorting lists is not crucial, I am rather indifferent about whether
> such a facility should exist and, if so, how it should be designed.
>
>
i discussed these things with you, because you responded. this made me
think you were not indifferent, but anyway i kept ccing to the list
precisely because because i don't think you're the right person to make
a decision or suggest the next steps.
>> telling me i have a chip on my shoulder is rather unhelpful.
>>
>
> Well, then stop acting as if you are running around with chips on your
> shoulders. Behaving in such a manner is rather counter productive in
> the R community (at least from my experience/observation).
why not read some fortunes?
"When a Certain Guru rips strips off people (God knows he's done it to
me often
enough) on this list, there's a damned good reason for it.
-- Rolf Turner (in a discussion about whether a friendly mailing list
with
more 'customer service' attitude than R-help was needed)
R-help (December 2003)"
when gurus are ripped strips off on this list, there's a damned good
reason for it.
(and i'm actually not doing it.) or:
"You may have not been long enough on this list to see that some of the
old-time
gurus have reached a demigod like status. Demigods have all rights to be
'rude'
(that's almost a definition of a demi-deity).
-- Jari Oksanen (in a discussion on whether answers on R-help should
be more
polite)
R-help (December 2004)"
which certainly documents a very productive approach to communication
with users.
<snip>
>>> And what makes you believe this is not the case? I have seen over
>>> the years e-mails to R-devel along the lines "I am thinking of a
>>> change along [lots of details and reasoning for the change]; would
>>> patches that implement this be accepted?" and these e-mails were
>>> discussed more often than not. However, in the end, the only
>>> people who can commit changes to the R code are the members of
>>> R-core, thus they will have the final word of design issues (and,
>>> as I assume, they discuss, among other things, design issues on the
>>> private mailing list of R-core member). But you can discuss this
>>> issues before writing a patch.
>>>
>> how many such mails have you seen?
>>
>
> A few over the years, but the more R progresses/matures the less of
> such e-mail happens.
>
>
a few over the years?
>> i've been on r-devel for six months, and haven't seen many.
>>
>
> Well, six month is a rather narrow sampling window....
>
your sampling window does not seem to provide better results.
>
>> on the other hand, i have seen quite a few responses that were
>> bashing a user for reporting a non-existent bug or submitting an
>> annoying patch.
>>
>
> In didactic terms those are "negative motivations/reinforcements";
> opinion differ on how effective they are to reach certain learning
> outcomes.
>
ah, so what's the difference between the way i pinpoint design flaws and
the way r gurus respond to people, so that i am running with a chip on
my shoulder, and they are being 'negatively motivating/reinforcing' in
didactic terms? (am i correct, is the 'negative
motivation/reinforcement' the same stuff jari oksanen talked about?)
>
>>> And I am sure that if you had sent an e-mail to r-devel pointing out
>>> that the binary operator <, when called in the non-standard way
>>> '<'(1,2,3), does not check the number of arguments while other
>>> binary operators (e.g. '+'(1,2,3) or '*'(1,2,3)) do such checks,
>>> and provided a patch that implemented such a check for '<' (and
>>> presumably other comparison operators), then that patch would have
>>> been acknowledged and applied.
>>>
>>>
>> it has been fixed immediately by martin.
>>
>
> Yes, and, again, you could not help yourself telling the developers
> what you think they should do, could you?
was this really running with a chip:
"shouldn't the tests have captured it? i think you should have a check
for every feature following from the docs."
to which marting responded "yes, we should"
> As I try to tell you, that
> is not the way it works. R comes already with extensive tests that are
> run with "make check". If you think some are missing, you could send a
> script and propose that they are included. But telling others that
> they should write such tests is unlikely to make it happen.
>
haven't done the thing.
vQ
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
