[R-package] change CRAN maintainer

[jameslamb]

Contributes to #5987.
Contributes to #6221.
Will help with the v4.2.0 release (#6191).

Proposes changing the maintainer ("cre") for the R package from @shiyu1994 to me.

I'd asked about this a few times, most recently in #6221 (comment), but we've never really discussed it. I'm opening this PR as a place to have that discussion.

What does this mean?

This would mean that the following feedback from CRAN all go to my personal email, instead of @shiyu1994 's work email:

• automated feedback on submissions (like failed CRAN checks, e.g. [R-package] CRAN error: r-devel-linux-x86_64-debian-clang #5502, [R-package] CRAN issue with unqualified call to 'std::move' #5661, [R-package] Warnings of CRAN Package #6221)
• warnings about pending deprecations (like the patches CRAN applied in the R 3-to-4 transition)
• issues that require our attention to keep the package on CRAN (like failing reverse dependency checks)
• other communication from CRAN to package maintainers

As described in https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file

*The mandatory ‘Maintainer’ field should give a single name... For a CRAN package it should be a person, not a mailing list and not a corporate entity: do ensure that it is valid and will remain valid for the lifetime of the package.

More descriptions on the role can be found in https://journal.r-project.org/archive/2012-1/RJournal_2012-1_Hornik~et~al.pdf.

Why do this?

Removes friction in the process of releasing the R package and reduces the risk of incidents like #4713 where {lightgbm} is removed from CRAN due to issues detected there + our response not being fast enough.

For most practical purposes, I have been the primary maintainer for the R package here fore the last 2+ years.

The process for releasing has been:

1. we cut a release
2. I submit the R package to CRAN, then ask @shiyu1994 to check his email and click a link
3. @shiyu1994 clicks the link
4. CRAN reports the status of that submission in an email to @shiyu1994 , and I don't know about it until @shiyu1994 posts here
5. if issues are found, @shiyu1994 posts here, someone (often me) tries to fix those issues, and resubmits
6. repeat steps 2-5

If I were CRAN's primary contact for the package, it would make this cycle faster. There would be no need for a separate waiting period for clicking that approval link, for example.

Is this allowed by Microsoft?

It should be. The {finnts} project from Microsoft, for example, has Maintainer set to a GMail account, not a Microsoft employee email.

https://github.com/microsoft/finnts/blob/37e6fb8bced45b18c0fac14b0374612f12f4f855/DESCRIPTION#L5-L9

https://cran.r-project.org/web/packages/finnts/index.html

Is this allowed by CRAN?

Absolutely. We changed the maintainer from @guolinke to @shiyu1994 back in #4633 and that change was allowed.

As described in https://cran.r-project.org/web/packages/policies.html#Submission

Explain any change in the maintainer’s email address and if possible send confirmation from the previous address (by a separate email to CRAN-submissions@R-project.org) or explain why it is not possible.

Notes for Reviewers

Thanks for your time and consideration.

And especially to you @shiyu1994 ... please don't think of this PR as a criticism. I am just trying to do what I can to keep {lightgbm} on CRAN, and to reduce a source of work for you, as I know you're quite busy. Thanks as always for your help!

I won't merge this without approvals from all of @shiyu1994 @guolinke and @jmoralez .

[shiyu1994]

Looks good to me.

[jameslamb]

@guolinke if you have time this week, could you please review this?

I'd like to include this change in a (hopeful) release to CRAN in the next few days.

Sorry for the @, but it's time-sensitive with CRAN threatening to archive the package if we don't fix the existing issues by December 12.

[jameslamb]

Thank you all! Will merge this once it builds.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.