Re: [R-pkg-devel] CRAN student assistants

[alejandro baranek]

Joris:
I'm sorry about your feelings about my thoughts based on Hadley's related
experience.
I feel lucky to be learning from this community. I'm an R user for many
years, but only became a package developer recently and don't have the
background neither the history in the community for putting in doubt the
efforts the CRAN team make. I red some statistics, but don't have a clear
idea of the amount of work involved in CRAN maintenance. Don't even know
where to look for documentation about it.

If you tell me how can I do, I gladly can give feedback with some
observations IN PRIVATE about  experiences we had publishing in CRAN, for
improving the experience both for the developers and for the maintainers.
I'm sure the problem I want to describe is now solved, because the alarm
was set by CRAN maintainers. It is a very small issue,  by the way.

If there is a way for helping, I'm here.

I repeat, I feel lucky for finding a project (R) where I feel contained in
many of my *strange* curiosity inquires.

All the best, Ale.



On Thu, May 16, 2019 at 2:41 PM Joris Meys  wrote:

> On Thu, May 16, 2019 at 4:59 PM Hadley Wickham 
> wrote:
>
> > Hi all,
> >
> > I am most interested in understanding what level of
> > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> > critique the implementation of R packages
>
>
> Ing. is the german title for "Engineer". You made her name public in the
> repositories of your own organisation. So at least have the decency to
> google her before you question her competence in public. Your obvious lack
> of understanding about the Austrian education system is no excuse for
> questioning her competence.
>
>
> > I mean no disrespect towards the CRAN maintainers
> >
>
> The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
> at the next R foundation in case you really need to know. The unrespectful
> thing to do, is to gaslight on a public mailing list to the point you make
> others, like Alejandro, question the competence of CRAN maintainers.
>
>
> >
> > I do recognise that my question "Who are they?" may have been
> > perceived as overly intrusive.
>
>
> The word is "bewildering", as you know their names, and your organisation
> shared personally identifying information (i.e. her email address which
> includes the institute she WORKS for) on their github repo.
>
>
> > To clarify: I don't want to know names
> > or other personally identifying information, but I would like to know
> > in general terms how many there are, and what backgrounds they have.
> >
>
> That's again something you can ask Dr. Ligges IN PRIVATE at the next R
> foundation meeting, and not a subject for an open mailing list. And after
> this exchange, I would totally understand if he refuses to answer that.
>
>
> > Similarly, I don't want to know how much they are paid, just whether
> > or not they are volunteers or employees.
> >
>
> The budgetary arrangements between a university and their _employee_ are of
> no concern to the mailing list. Asking about such arrangements for an
> employee that's not yours, is considered highly impolite in Europe.
>
> RStudio has been very vocal on numerous occasions about standards they
> hold. I would appreciate if the chief scientist of RStudio abides by those
> standards.
>
> Thank you.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
 alejandro baranek
@ken4rab 
qbotics  | rpolyhedra

| surferinvaders  | algebraic-soundscapes
 | surfer-shuffle


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Pedro J. Aphalo]

 From the other side of the fence, as an author and maintainer, I regret 
much more when both my own tests and CRAN's have failed to detect a 
problem than when I need to spend some effort to explain that something 
is a false positive. Considering the number of downloads from CRAN, a 
false negative test can cause grief and lost time to many users. A false 
positive causes some extra work only to the developer and CRAN 
maintainers, and I really appreciate the big effort that strict checks 
represents for them.

The other question that was implicit in the justification for the use of 
cat() is that the submission was "design in progress". I think the 
larger and more diverse the community of CRAN users becomes, the less 
justification there is for releasing packages at early stage of 
development through CRAN. Packages will evolve, but once they are in 
CRAN mostly by expanding functionality, rather than changes in design. 
Error handling and documentation should be good enough to ensure the 
package will not be wrongly used by accident. R and CRAN are no longer 
used mainly by statisticians and experts.

Best,

Pedro.

On 2019-05-16 22:42, Duncan Murdoch wrote:
> On 16/05/2019 1:10 p.m., Jennifer Bryan wrote:
>> Thanks for the excellent comparable package, Hong.
>>
>> Today's rejection of gargle instructs me to use \donttest{} instead of
>> \dontrun{}. Most of the affected functions create, load, and/or refresh
>> service account tokens and OAuth2 credentials. I see that \dontrun{} is
>> used in AzureAuth, which does seem more appropriate and is what I 
>> did. My
>> impression is that \donttest{} code is still run under some 
>> circumstances.
>> Perhaps this is another good topic for discussion, now that we've worked
>> through cat() vs message().
>>
>> It seems like you've also got a few functions without examples at all
>> (e.g., format_auth_header(), AzureR_dir()). How does this get through 
>> CRAN
>> review? When is that OK and when is it not?
>
> I haven't been involved with CRAN for a couple of years, but for the 
> year when I was, one thing that really, really pissed us off was a 
> question like this.  Obviously it is better if all functions have 
> examples.  When package authors tried to determine the absolute least 
> work they could get away with it really wasted our time trying to 
> decide which side of the line a particular package fell on.  We tried 
> to be consistent, but clearly that would be impossible.
>
> So the answer to your question is:  put excellent examples in all of 
> your help pages, and don't try to find the minimally publishable package.
>
>
>> I would simply like to understand the standards, so that I can impose 
>> them
>> on myself and go through fewer submissions. Maybe we could even automate
>> some of those checks. That would reduce workload all around.
>
> Impose higher standards on yourself than you think are necessary, and 
> your packages will be better and will be published faster.
>
> Duncan Murdoch
>
>> I've taken your advice to reply via email with full explanation and cc
>> others at CRAN. Maybe this will also lead to speedy resolution with 
>> no fuss.
>>
>> -- Jenny
>>
>> On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:
>>
>>> I had a similar experience with a couple of my package updates needing
>>> changes. The background is that I have a family of packages for 
>>> talking to
>>> Microsoft's Azure cloud service from R, and my examples are all marked
>>> \dontrun because they need an Azure subscription to work. This had
>>> previously been cleared with Uwe Ligges, but I guess the other CRAN
>>> reviewers weren't aware of this.
>>>
>>> In both cases, replying to the CRAN email and cc'ing Uwe resolved the
>>> issue quickly and without fuss.
>>>
>>>
>>> -Original Message-
>>> From: R-package-devel  On Behalf
>>> Of Mark van der Loo
>>> Sent: Thursday, 16 May 2019 1:50 AM
>>> To: Jennifer Bryan 
>>> Cc: R Package Development 
>>> Subject: Re: [R-pkg-devel] CRAN student assistants
>>>
>>> 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

Re: [R-pkg-devel] CRAN student assistants

[David Hugh-Jones]

Joris,

I have no dog in this fight, but I think you should cool down a bit. Hadley
explained why he thought these people were students: it’s the adjective
studentische in the job description. I don’t think he meant, or implied,
any disrespect to the individuals concerned. He is entitled to ask in
public about CRAN’s process, which is of concern to everybody who deals
with CRAN. Lastly, accusations of “gaslighting” are over the top, and
adding heat to this debate.

If you think it’s wrong to record  correspondence with CRAN in public, you
may have a point – that is a separate topic. I would lean that CRAN
responses ought not to be considered confidential, but perhaps identifying
information should be shared with care. These are quite subtle issues, so
again, thoughtful discussion would be great.

David


On Thu, 16 May 2019 at 18:41, Joris Meys  wrote:

> On Thu, May 16, 2019 at 4:59 PM Hadley Wickham 
> wrote:
>
> > Hi all,
> >
> > I am most interested in understanding what level of
> > discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> > critique the implementation of R packages
>
>
> Ing. is the german title for "Engineer". You made her name public in the
> repositories of your own organisation. So at least have the decency to
> google her before you question her competence in public. Your obvious lack
> of understanding about the Austrian education system is no excuse for
> questioning her competence.
>
>
> > I mean no disrespect towards the CRAN maintainers
> >
>
> The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
> at the next R foundation in case you really need to know. The unrespectful
> thing to do, is to gaslight on a public mailing list to the point you make
> others, like Alejandro, question the competence of CRAN maintainers.
>
>
> >
> > I do recognise that my question "Who are they?" may have been
> > perceived as overly intrusive.
>
>
> The word is "bewildering", as you know their names, and your organisation
> shared personally identifying information (i.e. her email address which
> includes the institute she WORKS for) on their github repo.
>
>
> > To clarify: I don't want to know names
> > or other personally identifying information, but I would like to know
> > in general terms how many there are, and what backgrounds they have.
> >
>
> That's again something you can ask Dr. Ligges IN PRIVATE at the next R
> foundation meeting, and not a subject for an open mailing list. And after
> this exchange, I would totally understand if he refuses to answer that.
>
>
> > Similarly, I don't want to know how much they are paid, just whether
> > or not they are volunteers or employees.
> >
>
> The budgetary arrangements between a university and their _employee_ are of
> no concern to the mailing list. Asking about such arrangements for an
> employee that's not yours, is considered highly impolite in Europe.
>
> RStudio has been very vocal on numerous occasions about standards they
> hold. I would appreciate if the chief scientist of RStudio abides by those
> standards.
>
> Thank you.
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
> <
> https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g
> >
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Duncan Murdoch]

On 16/05/2019 1:10 p.m., Jennifer Bryan wrote:

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh
service account tokens and OAuth2 credentials. I see that \dontrun{} is
used in AzureAuth, which does seem more appropriate and is what I did. My
impression is that \donttest{} code is still run under some circumstances.
Perhaps this is another good topic for discussion, now that we've worked
through cat() vs message().

It seems like you've also got a few functions without examples at all
(e.g., format_auth_header(), AzureR_dir()). How does this get through CRAN
review? When is that OK and when is it not?


I haven't been involved with CRAN for a couple of years, but for the 
year when I was, one thing that really, really pissed us off was a 
question like this.  Obviously it is better if all functions have 
examples.  When package authors tried to determine the absolute least 
work they could get away with it really wasted our time trying to decide 
which side of the line a particular package fell on.  We tried to be 
consistent, but clearly that would be impossible.


So the answer to your question is:  put excellent examples in all of 
your help pages, and don't try to find the minimally publishable package.




I would simply like to understand the standards, so that I can impose them
on myself and go through fewer submissions. Maybe we could even automate
some of those checks. That would reduce workload all around.


Impose higher standards on yourself than you think are necessary, and 
your packages will be better and will be published faster.


Duncan Murdoch


I've taken your advice to reply via email with full explanation and cc
others at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:


I had a similar experience with a couple of my package updates needing
changes. The background is that I have a family of packages for talking to
Microsoft's Azure cloud service from R, and my examples are all marked
\dontrun because they need an Azure subscription to work. This had
previously been cleared with Uwe Ligges, but I guess the other CRAN
reviewers weren't aware of this.

In both cases, replying to the CRAN email and cc'ing Uwe resolved the
issue quickly and without fuss.


-Original Message-
From: R-package-devel  On Behalf
Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

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 
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

Re: [R-pkg-devel] CRAN student assistants

[Hong Ooi via R-package-devel]

--- Begin Message ---
I don’t think they check _every_ help page for examples. My assumption would be 
that if the main functionality of the package is covered, then functions that 
are clearly ancillary, or whose usage is obvious, get a pass.

Another reason for cloud-related packages to mark things as \dontrun (as 
opposed to \donttest) would be if they deploy resources that have an associated 
cost. You probably don’t want to be charged 50 bucks, or whatever, for 
deploying a compute cluster just by running example().

From: Jennifer Bryan 
Sent: Friday, 17 May 2019 3:10 AM
To: Hong Ooi 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of 
\dontrun{}. Most of the affected functions create, load, and/or refresh service 
account tokens and OAuth2 credentials. I see that \dontrun{} is used in 
AzureAuth, which does seem more appropriate and is what I did. My impression is 
that \donttest{} code is still run under some circumstances. Perhaps this is 
another good topic for discussion, now that we've worked through cat() vs 
message().

It seems like you've also got a few functions without examples at all (e.g., 
format_auth_header(), AzureR_dir()). How does this get through CRAN review? 
When is that OK and when is it not?

I would simply like to understand the standards, so that I can impose them on 
myself and go through fewer submissions. Maybe we could even automate some of 
those checks. That would reduce workload all around.

I've taken your advice to reply via email with full explanation and cc others 
at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi 
mailto:hong...@microsoft.com>> wrote:
I had a similar experience with a couple of my package updates needing changes. 
The background is that I have a family of packages for talking to Microsoft's 
Azure cloud service from R, and my examples are all marked \dontrun because 
they need an Azure subscription to work. This had previously been cleared with 
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.

In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue 
quickly and without fuss.


-Original Message-
From: R-package-devel 
mailto:r-package-devel-boun...@r-project.org>>
 On Behalf Of Mark van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan mailto:jenny.f.br...@gmail.com>>
Cc: R Package Development 
mailto:r-package-devel@r-project.org>>
Subject: Re: [R-pkg-devel] CRAN student assistants

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 
mailto:jenny.f.br...@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 curre

Re: [R-pkg-devel] CRAN student assistants

[Joris Meys]

On Thu, May 16, 2019 at 4:59 PM Hadley Wickham  wrote:

> Hi all,
>
> I am most interested in understanding what level of
> discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> critique the implementation of R packages


Ing. is the german title for "Engineer". You made her name public in the
repositories of your own organisation. So at least have the decency to
google her before you question her competence in public. Your obvious lack
of understanding about the Austrian education system is no excuse for
questioning her competence.


> I mean no disrespect towards the CRAN maintainers
>

The respectful thing to do, is to discuss this IN PRIVATE with Dr. Ligges
at the next R foundation in case you really need to know. The unrespectful
thing to do, is to gaslight on a public mailing list to the point you make
others, like Alejandro, question the competence of CRAN maintainers.


>
> I do recognise that my question "Who are they?" may have been
> perceived as overly intrusive.


The word is "bewildering", as you know their names, and your organisation
shared personally identifying information (i.e. her email address which
includes the institute she WORKS for) on their github repo.


> To clarify: I don't want to know names
> or other personally identifying information, but I would like to know
> in general terms how many there are, and what backgrounds they have.
>

That's again something you can ask Dr. Ligges IN PRIVATE at the next R
foundation meeting, and not a subject for an open mailing list. And after
this exchange, I would totally understand if he refuses to answer that.


> Similarly, I don't want to know how much they are paid, just whether
> or not they are volunteers or employees.
>

The budgetary arrangements between a university and their _employee_ are of
no concern to the mailing list. Asking about such arrangements for an
employee that's not yours, is considered highly impolite in Europe.

RStudio has been very vocal on numerous occasions about standards they
hold. I would appreciate if the chief scientist of RStudio abides by those
standards.

Thank you.

-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Jennifer Bryan]

Thanks for the excellent comparable package, Hong.

Today's rejection of gargle instructs me to use \donttest{} instead of
\dontrun{}. Most of the affected functions create, load, and/or refresh
service account tokens and OAuth2 credentials. I see that \dontrun{} is
used in AzureAuth, which does seem more appropriate and is what I did. My
impression is that \donttest{} code is still run under some circumstances.
Perhaps this is another good topic for discussion, now that we've worked
through cat() vs message().

It seems like you've also got a few functions without examples at all
(e.g., format_auth_header(), AzureR_dir()). How does this get through CRAN
review? When is that OK and when is it not?

I would simply like to understand the standards, so that I can impose them
on myself and go through fewer submissions. Maybe we could even automate
some of those checks. That would reduce workload all around.

I've taken your advice to reply via email with full explanation and cc
others at CRAN. Maybe this will also lead to speedy resolution with no fuss.

-- Jenny

On Wed, May 15, 2019 at 2:18 PM Hong Ooi  wrote:

> I had a similar experience with a couple of my package updates needing
> changes. The background is that I have a family of packages for talking to
> Microsoft's Azure cloud service from R, and my examples are all marked
> \dontrun because they need an Azure subscription to work. This had
> previously been cleared with Uwe Ligges, but I guess the other CRAN
> reviewers weren't aware of this.
>
> In both cases, replying to the CRAN email and cc'ing Uwe resolved the
> issue quickly and without fuss.
>
>
> -Original Message-
> From: R-package-devel  On Behalf
> Of Mark van der Loo
> Sent: Thursday, 16 May 2019 1:50 AM
> To: Jennifer Bryan 
> Cc: R Package Development 
> Subject: Re: [R-pkg-devel] CRAN student assistants
>
> 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 
> 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.
> >
> > -- Je

Re: [R-pkg-devel] CRAN student assistants

[alejandro baranek]

Hi!

Mi humble opinion:

I cannot evaluate the workload for CRAN maintainer, but it don't seem to be
reasonable that students can make objections with packages that "do not
yield R CMD check problems or otherwise violate CRAN policies."

Maybe CRAN maintainer team are giving review tasks for those students, for
increasing package evaluation skills. But a new protocol should be
implemented with this seamly new position, where students learning errors
doesn't obstruct the workflow of senior package developers with own QA
methods implemented, as a result of years efforts.

Is not bad new workforce helps with heavy duties: it's an excelent news.
But It cannot cause problems with tunned workflow/pipelines. Is the
internal CRAN process for package approval described somewhere?

Best, Ale.

On Thu, May 16, 2019 at 11:55 AM Hadley Wickham  wrote:

> Hi all,
>
> The thread seems to have drifted off topic. I really didn't want this
> to devolve into a discussion about when cat() or message() is more
> appropriate — I have complete faith in Jenny Bryan's ability to
> understand technical tradeoffs and pick the most appropriate given the
> constraints. I am most interested in understanding what level of
> discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
> critique the implementation of R packages, particularly for packages
> that do not yield R CMD check problems or otherwise violate CRAN
> policies.
>
> I mean no disrespect towards the CRAN maintainers (whose tireless
> efforts are a crucial part of making R the success that it is), but I
> don't think it's unreasonable to enquire as to who is involved in a
> crucial piece of open source community infrastructure, and, if
> students are involved, what their scope of work is and how they are
> trained and supervised.
>
> I do recognise that my question "Who are they?" may have been
> perceived as overly intrusive. To clarify: I don't want to know names
> or other personally identifying information, but I would like to know
> in general terms how many there are, and what backgrounds they have.
> Similarly, I don't want to know how much they are paid, just whether
> or not they are volunteers or employees.
>
> Hadley
>
> On Tue, May 14, 2019 at 10:23 AM Hadley Wickham 
> wrote:
> >
> > Hi all,
> >
> > Several people on my team have received responses to their CRAN
> > submissions from new members of the CRAN team who appear to be student
> > assistants (judging from their job titles: "Studentischer
> > administrativer Mitarbeiter"). From the outside, they appear to be
> > exercising editorial control[^1] and conducting design reviews[^2].
> >
> > CRAN is a critical piece of R community infrastructure, and I am sure
> > these students have been surrounded by the proper checks and balances,
> > but it's not obvious what their role is from the outside. I'd really
> > appreciate knowing a little more about them:
> >
> > * Who are they?
> >
> > * Are they paid employees or volunteers?
> >
> > * What is their scope of work?
> >
> > * How are they trained?
> >
> > * If we believe that they have made a mistake, how do we request
> >   review from a senior CRAN member?
> >
> > * They appear to be able to apply additional discretionary criteria
> >   that are not included in R CMD check or documented in the CRAN
> policies.
> >   Is this true? If so, what is the scope of these additional checks?
> >
> > Hadley
> >
> > [^1]: The devoid package was rejected because the student assistant
> > did not understand the purpose of the package.
> >
> > [^2]: The gargle package was rejected because the student assistant
> > believed that the use of cat() was incorrect. It was not.
> >
> > --
> > http://hadley.nz
>
>
>
> --
> http://hadley.nz
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
 alejandro baranek
@ken4rab 
qbotics  | rpolyhedra

| surferinvaders  | algebraic-soundscapes
 | surfer-shuffle


[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Hadley Wickham]

Hi all,

The thread seems to have drifted off topic. I really didn't want this
to devolve into a discussion about when cat() or message() is more
appropriate — I have complete faith in Jenny Bryan's ability to
understand technical tradeoffs and pick the most appropriate given the
constraints. I am most interested in understanding what level of
discretion CRAN's "Studentischer administrativer Mitarbeiter" have to
critique the implementation of R packages, particularly for packages
that do not yield R CMD check problems or otherwise violate CRAN
policies.

I mean no disrespect towards the CRAN maintainers (whose tireless
efforts are a crucial part of making R the success that it is), but I
don't think it's unreasonable to enquire as to who is involved in a
crucial piece of open source community infrastructure, and, if
students are involved, what their scope of work is and how they are
trained and supervised.

I do recognise that my question "Who are they?" may have been
perceived as overly intrusive. To clarify: I don't want to know names
or other personally identifying information, but I would like to know
in general terms how many there are, and what backgrounds they have.
Similarly, I don't want to know how much they are paid, just whether
or not they are volunteers or employees.

Hadley

On Tue, May 14, 2019 at 10:23 AM Hadley Wickham  wrote:
>
> Hi all,
>
> Several people on my team have received responses to their CRAN
> submissions from new members of the CRAN team who appear to be student
> assistants (judging from their job titles: "Studentischer
> administrativer Mitarbeiter"). From the outside, they appear to be
> exercising editorial control[^1] and conducting design reviews[^2].
>
> CRAN is a critical piece of R community infrastructure, and I am sure
> these students have been surrounded by the proper checks and balances,
> but it's not obvious what their role is from the outside. I'd really
> appreciate knowing a little more about them:
>
> * Who are they?
>
> * Are they paid employees or volunteers?
>
> * What is their scope of work?
>
> * How are they trained?
>
> * If we believe that they have made a mistake, how do we request
>   review from a senior CRAN member?
>
> * They appear to be able to apply additional discretionary criteria
>   that are not included in R CMD check or documented in the CRAN policies.
>   Is this true? If so, what is the scope of these additional checks?
>
> Hadley
>
> [^1]: The devoid package was rejected because the student assistant
> did not understand the purpose of the package.
>
> [^2]: The gargle package was rejected because the student assistant
> believed that the use of cat() was incorrect. It was not.
>
> --
> http://hadley.nz



-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Hong Ooi via R-package-devel]

--- Begin Message ---
I had a similar experience with a couple of my package updates needing changes. 
The background is that I have a family of packages for talking to Microsoft's 
Azure cloud service from R, and my examples are all marked \dontrun because 
they need an Azure subscription to work. This had previously been cleared with 
Uwe Ligges, but I guess the other CRAN reviewers weren't aware of this.
 
In both cases, replying to the CRAN email and cc'ing Uwe resolved the issue 
quickly and without fuss.


-Original Message-
From: R-package-devel  On Behalf Of Mark 
van der Loo
Sent: Thursday, 16 May 2019 1:50 AM
To: Jennifer Bryan 
Cc: R Package Development 
Subject: Re: [R-pkg-devel] CRAN student assistants

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 
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 
> 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 
> > 
> > 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 ma

Re: [R-pkg-devel] CRAN student assistants

[Duncan Murdoch]

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  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 
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 

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,

Re: [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 
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 
> 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 
> > 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  >
> > 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 

Re: [R-pkg-devel] CRAN student assistants

[Jennifer Bryan]

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  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 
> 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 
> 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-boun...@r-project.org on behalf of joris.m...@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@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

Re: [R-pkg-devel] CRAN student assistants

[John Mount]

Dialogue is not always getting what you demand in one step.  One form dialogue 
with CRAN is re-submitting with CRAN-correspondence stating what one wants.

Also, for a lot of applications being able to turn off messages is critical.

> 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  > 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

---
John Mount
http://www.win-vector.com/  
Our book: Practical Data Science with R 
https://www.manning.com/books/practical-data-science-with-r-second-edition 






[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Jim Hester]

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  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  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" 
> >  
> > 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@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Jim Hester]

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  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" 
>  
> 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[Martin Morgan]

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" 
 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] CRAN student assistants

[David C Sterratt]

Dear all,

as a CRAN contributor, I am interested in answers to the questions
Hadley raises.

I very much appreciate the huge amount of work the CRAN team do. I get
the impression that hitherto much of it has been funded by "goodwill".
That's not sustainable and it definitely needs to be staffed
sufficiently.

As a contributor I've come to expect that I have to abide by the
submission guidelines, and that with every release of R the checks get
more stringent. This is a very good thing for the quality of code, even
if it makes me curse at the time!

I've also come to expect some comments on things like the formatting of
quotes in the package description.

I maintain one package (geometry) on a goodwill basis. It's not related
to my current work, and I get little academic credit for it. Unexpected
comments at the final stages of submission deplete goodwill. It would be
helpful to know what to expect, especially if standards are becoming
more stringent.

Best wishes,

David

On Wed 15 May 2019 at 09:45 GMT, Joris Meys  wrote:

> Dear Hadley,
>
> a follow up mail: You know who they are. Your organisation has the policy
> to add all email correspondence with CRAN to the github repo.
>
> https://github.com/r-lib/gargle/tree/master/cran-correspondence
>
> That's how I now also found out who they are. One is a doctor. She has a
> PhD. The mere fact you insinuate that this woman could be a student, is
> disturbing. The other obtained an engineer degree in 2011, and is currently
> obtaining a second one in Economics while working as a project assistant.
> Also here I find it disturbing you question the competence of someone with
> that experience, and who was selected by people known for their
> thoroughness.
>
> In light of this new information, I fail to understand why you even bother
> asking for information you had already. I would appreciate if you would
> stop gaslighting about CRAN and show those ladies the respect they deserve.
>
> Kind regards
> Joris
>
> On Wed, May 15, 2019 at 11:06 AM Joris Meys  wrote:
>
>> Dear Hadley,
>>
>> given you're on the list of R foundation members, I rest assured you have
>> other channels to ask about the identity of new CRAN staff directly to
>> those responsible. Their names and paychecks are of no interest to the
>> general dev world. I can understand CRAN doesn't want to make these names
>> public, in order to avoid thousands of beginning devs mailing them directly
>> with questions that should be answered elsewhere.
>>
>> I'd like to take a moment to thank CRAN for extending their workforce.
>> Given the increased workload, this was long overdue. I'm fully confident
>> the responsible CRAN maintainers made a thorough selection of competent
>> people. They're not known for their laissez-faire attitude.
>>
>> I further note that:
>>
>> 1) the devoid package is on CRAN.
>>
>> 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
>>
>> This is how I train my students, but you're entitled to your own opinion
>> obviously. When the opinion of a dev differs from CRAN however, it's up to
>> them to argue with CRAN about why their vision is correct. A third party
>> public complaint seems to be the norm lately, but in our region such things
>> are generally frowned upon, as it's considered basic politeness to solve
>> differences with the people directly.
>>
>> Finally, I'd like to point out that one can easily use the argument
>> "repos" in install.packages() to install from a different repository. So
>> there's absolutely no problem to have your own repo where you hire the
>> people and make the rules. That might save you a few emails to the dev
>> lists.
>>
>> I hope your ongoing problems with CRAN get resolved soon.
>> All the best.
>>
>> Joris
>>
>> On Tue, May 14, 2019 at 5:26 PM Hadley Wickham 
>> wrote:
>>
>>> Hi all,
>>>
>>> Several people on my team have received responses to their CRAN
>>> submissions from new members of the CRAN team who appear to be student
>>> assistants (judging from their job titles: "Studentischer
>>> administrativer Mitarbeiter"). From the outside, they appear to be
>>> exercising editorial control[^1] and conducting design reviews[^2].
>>>
>>> CRAN is a critical piece of R community infrastructure, and I am sure
>>> these students have been surrounded by the proper checks and balances,
>>> but it's not obvious what their role is from the outside. I'd really
>>> appreciate knowing a little more about them:
>>>
>>> * Who are they?
>>>
>>> * Are they paid employees or volunteers?
>>>
>>> * What is their scope of work?
>>>
>>> * How are they trained?
>>>
>>> * If we believe that they have made a mistake, how do we request
>>>   review from a senior CRAN member?
>>>
>>> * They appear to be able to apply additional discretionary criteria
>>>   that are not included in R CMD check or documented in the CRAN policies.
>>>   

Re: [R-pkg-devel] CRAN student assistants

[Hugh Parsonage]

I can't speak for Hadley, but my read of his email was that CRAN has
appointed new staff and while extra staff are clearly justified, it
was unclear how they were appointed and whether they had equal
seniority and authority as existing members. Indeed, the fact they use
titles which are clearly junior would suggest that they may not be.
His citation of the initially rejected packages was, from my read, not
intended to obtain special treatment for those packages, but simply to
make transparent his perception.

His request for additional details about the new appointments did not
strike me as too concerning either. My take was that he was not
wanting to find out more about the individuals themselves but to
better understand the process by which the CRAN team is formed. I
would echo his desire to better understand the process. CRAN (as
opposed to an arbitrary CRAN-like repository) is, as you and Hadley
agree, widely well-regarded. But outsiders -- for example systems
administrators of enterprise networks who are new to R -- may ask R
users to conduct due diligence on CRAN before whitelisting packages.
Some basic knowledge about the vetting and appointment of the
gatekeepers may be crucial in these matters. Naturally, CRAN as a free
service has no obligation at all to disclose such information nor to
assist with others' navigation of IT systems. But one is entitled to
ask.

Of course, Hadley could find all this out for himself, but this would
not be helpful to me and other outsiders. And I think this is what
motivated him to post publicly.

CRAN administration is a highly specialized job involving judgement
and experience; and so a criticism over the handling of one or two
submissions by obviously new appointees is hardly a reflection of the
individuals' general competence. If Uwe can make such mistakes, I
hardly think an error or two by someone else is that damning!



On 15/05/2019, Joris Meys  wrote:
> Dear Hadley,
>
> a follow up mail: You know who they are. Your organisation has the policy
> to add all email correspondence with CRAN to the github repo.
>
> https://github.com/r-lib/gargle/tree/master/cran-correspondence
>
> That's how I now also found out who they are. One is a doctor. She has a
> PhD. The mere fact you insinuate that this woman could be a student, is
> disturbing. The other obtained an engineer degree in 2011, and is currently
> obtaining a second one in Economics while working as a project assistant.
> Also here I find it disturbing you question the competence of someone with
> that experience, and who was selected by people known for their
> thoroughness.
>
> In light of this new information, I fail to understand why you even bother
> asking for information you had already. I would appreciate if you would
> stop gaslighting about CRAN and show those ladies the respect they deserve.
>
> Kind regards
> Joris
>
> On Wed, May 15, 2019 at 11:06 AM Joris Meys  wrote:
>
>> Dear Hadley,
>>
>> given you're on the list of R foundation members, I rest assured you have
>> other channels to ask about the identity of new CRAN staff directly to
>> those responsible. Their names and paychecks are of no interest to the
>> general dev world. I can understand CRAN doesn't want to make these names
>> public, in order to avoid thousands of beginning devs mailing them
>> directly
>> with questions that should be answered elsewhere.
>>
>> I'd like to take a moment to thank CRAN for extending their workforce.
>> Given the increased workload, this was long overdue. I'm fully confident
>> the responsible CRAN maintainers made a thorough selection of competent
>> people. They're not known for their laissez-faire attitude.
>>
>> I further note that:
>>
>> 1) the devoid package is on CRAN.
>>
>> 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
>>
>> This is how I train my students, but you're entitled to your own opinion
>> obviously. When the opinion of a dev differs from CRAN however, it's up
>> to
>> them to argue with CRAN about why their vision is correct. A third party
>> public complaint seems to be the norm lately, but in our region such
>> things
>> are generally frowned upon, as it's considered basic politeness to solve
>> differences with the people directly.
>>
>> Finally, I'd like to point out that one can easily use the argument
>> "repos" in install.packages() to install from a different repository. So
>> there's absolutely no problem to have your own repo where you hire the
>> people and make the rules. That might save you a few emails to the dev
>> lists.
>>
>> I hope your ongoing problems with CRAN get resolved soon.
>> All the best.
>>
>> Joris
>>
>> On Tue, May 14, 2019 at 5:26 PM Hadley Wickham 
>> wrote:
>>
>>> Hi all,
>>>
>>> Several people on my team have received responses to their CRAN
>>> submissions from new members of the CRAN team who appear to be 

Re: [R-pkg-devel] CRAN student assistants

[Joris Meys]

Dear Hadley,

a follow up mail: You know who they are. Your organisation has the policy
to add all email correspondence with CRAN to the github repo.

https://github.com/r-lib/gargle/tree/master/cran-correspondence

That's how I now also found out who they are. One is a doctor. She has a
PhD. The mere fact you insinuate that this woman could be a student, is
disturbing. The other obtained an engineer degree in 2011, and is currently
obtaining a second one in Economics while working as a project assistant.
Also here I find it disturbing you question the competence of someone with
that experience, and who was selected by people known for their
thoroughness.

In light of this new information, I fail to understand why you even bother
asking for information you had already. I would appreciate if you would
stop gaslighting about CRAN and show those ladies the respect they deserve.

Kind regards
Joris

On Wed, May 15, 2019 at 11:06 AM Joris Meys  wrote:

> Dear Hadley,
>
> given you're on the list of R foundation members, I rest assured you have
> other channels to ask about the identity of new CRAN staff directly to
> those responsible. Their names and paychecks are of no interest to the
> general dev world. I can understand CRAN doesn't want to make these names
> public, in order to avoid thousands of beginning devs mailing them directly
> with questions that should be answered elsewhere.
>
> I'd like to take a moment to thank CRAN for extending their workforce.
> Given the increased workload, this was long overdue. I'm fully confident
> the responsible CRAN maintainers made a thorough selection of competent
> people. They're not known for their laissez-faire attitude.
>
> I further note that:
>
> 1) the devoid package is on CRAN.
>
> 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
>
> This is how I train my students, but you're entitled to your own opinion
> obviously. When the opinion of a dev differs from CRAN however, it's up to
> them to argue with CRAN about why their vision is correct. A third party
> public complaint seems to be the norm lately, but in our region such things
> are generally frowned upon, as it's considered basic politeness to solve
> differences with the people directly.
>
> Finally, I'd like to point out that one can easily use the argument
> "repos" in install.packages() to install from a different repository. So
> there's absolutely no problem to have your own repo where you hire the
> people and make the rules. That might save you a few emails to the dev
> lists.
>
> I hope your ongoing problems with CRAN get resolved soon.
> All the best.
>
> Joris
>
> On Tue, May 14, 2019 at 5:26 PM Hadley Wickham 
> wrote:
>
>> Hi all,
>>
>> Several people on my team have received responses to their CRAN
>> submissions from new members of the CRAN team who appear to be student
>> assistants (judging from their job titles: "Studentischer
>> administrativer Mitarbeiter"). From the outside, they appear to be
>> exercising editorial control[^1] and conducting design reviews[^2].
>>
>> CRAN is a critical piece of R community infrastructure, and I am sure
>> these students have been surrounded by the proper checks and balances,
>> but it's not obvious what their role is from the outside. I'd really
>> appreciate knowing a little more about them:
>>
>> * Who are they?
>>
>> * Are they paid employees or volunteers?
>>
>> * What is their scope of work?
>>
>> * How are they trained?
>>
>> * If we believe that they have made a mistake, how do we request
>>   review from a senior CRAN member?
>>
>> * They appear to be able to apply additional discretionary criteria
>>   that are not included in R CMD check or documented in the CRAN policies.
>>   Is this true? If so, what is the scope of these additional checks?
>>
>> Hadley
>>
>> [^1]: The devoid package was rejected because the student assistant
>> did not understand the purpose of the package.
>>
>> [^2]: The gargle package was rejected because the student assistant
>> believed that the use of cat() was incorrect. It was not.
>>
>> --
>> http://hadley.nz
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>
> --
> Joris Meys
> Statistical consultant
>
> Department of Data Analysis and Mathematical Modelling
> Ghent University
> Coupure Links 653, B-9000 Gent (Belgium)
>
> 
>
> tel: +32 (0)9 264 61 79
> ---
> Biowiskundedagen 2017-2018
> http://www.biowiskundedagen.ugent.be/
>
> ---
> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
>


-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)

Re: [R-pkg-devel] CRAN student assistants

[Joris Meys]

Dear Hadley,

given you're on the list of R foundation members, I rest assured you have
other channels to ask about the identity of new CRAN staff directly to
those responsible. Their names and paychecks are of no interest to the
general dev world. I can understand CRAN doesn't want to make these names
public, in order to avoid thousands of beginning devs mailing them directly
with questions that should be answered elsewhere.

I'd like to take a moment to thank CRAN for extending their workforce.
Given the increased workload, this was long overdue. I'm fully confident
the responsible CRAN maintainers made a thorough selection of competent
people. They're not known for their laissez-faire attitude.

I further note that:

1) the devoid package is on CRAN.

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

This is how I train my students, but you're entitled to your own opinion
obviously. When the opinion of a dev differs from CRAN however, it's up to
them to argue with CRAN about why their vision is correct. A third party
public complaint seems to be the norm lately, but in our region such things
are generally frowned upon, as it's considered basic politeness to solve
differences with the people directly.

Finally, I'd like to point out that one can easily use the argument "repos"
in install.packages() to install from a different repository. So there's
absolutely no problem to have your own repo where you hire the people and
make the rules. That might save you a few emails to the dev lists.

I hope your ongoing problems with CRAN get resolved soon.
All the best.

Joris

On Tue, May 14, 2019 at 5:26 PM Hadley Wickham  wrote:

> Hi all,
>
> Several people on my team have received responses to their CRAN
> submissions from new members of the CRAN team who appear to be student
> assistants (judging from their job titles: "Studentischer
> administrativer Mitarbeiter"). From the outside, they appear to be
> exercising editorial control[^1] and conducting design reviews[^2].
>
> CRAN is a critical piece of R community infrastructure, and I am sure
> these students have been surrounded by the proper checks and balances,
> but it's not obvious what their role is from the outside. I'd really
> appreciate knowing a little more about them:
>
> * Who are they?
>
> * Are they paid employees or volunteers?
>
> * What is their scope of work?
>
> * How are they trained?
>
> * If we believe that they have made a mistake, how do we request
>   review from a senior CRAN member?
>
> * They appear to be able to apply additional discretionary criteria
>   that are not included in R CMD check or documented in the CRAN policies.
>   Is this true? If so, what is the scope of these additional checks?
>
> Hadley
>
> [^1]: The devoid package was rejected because the student assistant
> did not understand the purpose of the package.
>
> [^2]: The gargle package was rejected because the student assistant
> believed that the use of cat() was incorrect. It was not.
>
> --
> http://hadley.nz
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>


-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)


tel: +32 (0)9 264 61 79
---
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] CRAN student assistants

[Hadley Wickham]

Hi all,

Several people on my team have received responses to their CRAN
submissions from new members of the CRAN team who appear to be student
assistants (judging from their job titles: "Studentischer
administrativer Mitarbeiter"). From the outside, they appear to be
exercising editorial control[^1] and conducting design reviews[^2].

CRAN is a critical piece of R community infrastructure, and I am sure
these students have been surrounded by the proper checks and balances,
but it's not obvious what their role is from the outside. I'd really
appreciate knowing a little more about them:

* Who are they?

* Are they paid employees or volunteers?

* What is their scope of work?

* How are they trained?

* If we believe that they have made a mistake, how do we request
  review from a senior CRAN member?

* They appear to be able to apply additional discretionary criteria
  that are not included in R CMD check or documented in the CRAN policies.
  Is this true? If so, what is the scope of these additional checks?

Hadley

[^1]: The devoid package was rejected because the student assistant
did not understand the purpose of the package.

[^2]: The gargle package was rejected because the student assistant
believed that the use of cat() was incorrect. It was not.

-- 
http://hadley.nz

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel