[R-pkg-devel] CRAN student assistants

[Mark van der Loo]

For what it's worth,

I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a
few that with good reasons I could not change. I explained this in the
comments when uploading a new version and it got accepted. So I don't see
the problem.

(The case here was a use of \dontrun{}. I had to switch an example off
because a warning was thrown which would upset R CMD check. But
demonstrating the warning was exactly the point of the example.)

All this aside. I think it is extremely unethical to publish privately sent
CRAN emails on GH, including personal details such as name and e-mail
address of the sender without their explicit consent.


Best,
Mark





On Wed, May 15, 2019 at 4:44 PM Jennifer Bryan <jenny.f.bryan using gmail.com>
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.
> 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
>

	[[alternative HTML version deleted]]