[R-pkg-devel] CRAN student assistants
Hugh Parsonage
hugh@p@r@on@ge @end|ng |rom gm@||@com
Wed May 15 12:34:54 CEST 2019
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 <Joris.Meys using ugent.be> 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 <Joris.Meys using ugent.be> 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 <h.wickham using gmail.com>
>> 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 using 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)
>>
>> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
>>
>> 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)
> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
More information about the R-package-devel
mailing list