[R-pkg-devel] CRAN student assistants

Wed May 15 18:15:09 CEST 2019

On 15/05/2019 10:40 a.m., Jennifer Bryan wrote:
> Hello,
> 
> Since this has turned into a worldwide code review, I will briefly address
> that, then reiterate the point of the original message.
> 
> I am working on an initial release of a package. It reveals information to
> a user, sometimes in a print method-y way, sometimes in more of a verbose /
> debugging way that is under control of a documented option, which defaults
> to "off" or "quiet". For now, I have chosen to send all of this output
> through a single functions that, yes, uses cat(). I went this direction for
> an initial release to keep the package simple and accumulate some user
> experience. If the "debugging mode" proves to be useful, I will rework it,
> possibly using UI functionality that I believe our group might release in
> the future. Rest assured, I understand cat() vs message() and the various
> tradeoffs. I made mine and it is my impression that package maintainers
> have this level of freedom.
> 
> The real point is: the currenrt CRAN submission process is designed for
> one-way communication and there's no guarantee of continuity of reviewer.

I don't see how you and Jim can claim this is "one way" communication. 
You are supposed to write a message to accompany your submission, and 
you did receive a message from CRAN complaining about something you did. 
  That's two way communication.

Sometimes you'll correct whatever complaint they had, and sometimes 
you'll disagree.  In either case, you should be explaining your decision 
in your next submission message.

Yes, you might get another reviewer next time, but you can make that 
less of a problem (maybe less likely, I don't know current procedures) 
by quoting the complaint when you resubmit.

You'd like to have a discussion with the CRAN reviewer in between 
submissions.  That's not really feasible, given that there are hundreds 
of times as many of us package authors as there are of CRAN reviewers.

That's why we set up this mailing list:  if you don't understand a 
message you receive from CRAN, copy it here, and others (probably not 
CRAN reviewers) will try to explain what the complaint was about.  If 
you still disagree with CRAN's decision after a resubmission, you can 
also ask for advice here.

Duncan Murdoch

> If this type of implementation review is going to happen, it seems that
> many aspects of the process would need to change, to make sure these new
> standards are applied consistently to every submission and that existing
> package are brought up to current standards.
> 
> To clarify something for Joris, I am not aware of any special channel of
> communication or influence between CRAN and the R Foundation (of which I am
> also a member). I think this is an aspect of CRAN vs R Foundation (vs R
> Core even) that is unclear to many. These entities operate quite
> independently, except for the fact that specific people belong to more than
> one. So RF members interact with CRAN the same way as any other of member
> of the community.
> 
> -- Jenny
> 
> On Wed, May 15, 2019 at 6:43 AM Jim Hester <james.f.hester using gmail.com> wrote:
> 
>> Sorry first sentence should read
>>
>> I agree that `message()` is ideally preferred, precisely because
>> of the reasons Martin stated, it is easily controlled by the user.
>>
>> On Wed, May 15, 2019 at 9:41 AM Jim Hester <james.f.hester using gmail.com>
>> wrote:
>>>
>>> I agree that `message()` is in an ideally preferred, precisely because
>>> of the reasons Martin stated, it is easily controlled by the user.
>>>
>>> Unfortunately, in the real world, the windows R gui console and
>>> RStudio (which copied behavior) color messages, and anything on stderr
>>> in fact, in red, which confuses most users who are trained to treat
>>> messages in red as errors.
>>>
>>> This also makes using colored output (where available) more
>>> challenging when using `message()`.  You either have to accept the
>>> text as red, or unconditionally change the text color to black or
>>> similar, which can then be unreadable if the user is using a dark
>>> color theme.
>>>
>>> Jenny is an experienced package developer. She knew this tradeoff and
>>> the use of `cat()` in gargle was deliberate choice in an imperfect
>>> world. She did not make this decision out of ignorance of a better
>>> way.
>>>
>>> However there is no way for Jenny or any other package developers to
>>> have a dialog during a CRAN submission, the communication is only in
>>> one direction, if she resubmits explaining her rationale for the
>>> choice she may not even have the same reviewer the next time.
>>>
>>> Bioconductor seems to have a much better review process for
>>> submissions, with real dialog between the reviewer and package author,
>>> perhaps CRAN can learn from that process and improve the submission
>>> experience in the future.
>>>
>>> Jim
>>>
>>> On Wed, May 15, 2019 at 7:41 AM Martin Morgan <mtmorgan.bioc using gmail.com>
>> wrote:
>>>>
>>>> message() / warning() / stop() write to stderr whereas print() / cat()
>> write (by default) to stdout. Even without being able to suppress messages,
>> it is well-established practice (the story is that this is the reason why
>> 'stderr' was introduced into unix,
>> https://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
>> ) to separate diagnostic messages from program output. I agree that gargle
>> (in particular, and packages in general, given the theme of this mailing
>> list) would be a better package if it used message() where it now uses
>> cat().
>>>>
>>>> Martin
>>>>
>>>> On 5/15/19, 5:04 AM, "R-package-devel on behalf of Joris Meys" <
>> r-package-devel-bounces using r-project.org on behalf of Joris.Meys using ugent.be>
>> wrote:
>>>>
>>>>      2) Where cat() is used in gargle, message() is a better option for
>> the
>>>>      following reason:
>>>>
>>>>      > myfun <- function(){cat("Yes");message("No")}
>>>>      > suppressMessages(myfun())
>>>>      Yes
>>>>
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>