Usethis: Consider encouraging the use of ORCID IDs in DESCRIPTION template

Created on 6 Nov 2017  路  16Comments  路  Source: r-lib/usethis

usethis promotes the use of machine-readable Authors@R format already, by providing an editable template:

Authors@R: person("First", "Last", email = "[email protected]", role = c("aut", "cre"))

With CRAN supporting ORCID ids via the comment field,usethis could consider promoting this practice as well, e.g.:

Authors@R: person("First", "Last",
  email = "[email protected]",
  role = c("aut", "cre"), comment = c(ORCID = "https://add_your_orcid_id"))
description feature help wanted wip

All 16 comments

I wonder if we generally need some better tooling for saying "this is my name, email address, and orc id"

Yes, it would be great if utils::person had a field for id. Maybe orcid specifically, though maybe simply supporting URL would be a good start. (Generally I think schema.org is a good and popular standard for thinking about additional metadata terms).

For the moment, drafting the comment field as above seems to have some momentum; e.g. https://github.com/hadley/pkgdown/issues/421 and

Maybe we should have use_author() ?

Quick exploration:

#' Add an author to `Authors@R`
#'
#' @param given,family Given and family names. Can be vectors
#' @param email Email address. Mandatory for maintainers; optional otherwise.
#' @param role Character vector of roles.
#' @param comment Any additional comments
#' @param orcid ORCID (<http://orcid.org/>) identifier
#' @noRd
use_author <- function(given, family, email = NULL, role = "ctb",
                       comment = NULL, orcid = NULL) {

  comment <- c(comment, ORCID = orcid)

  desc::desc_add_author(
    file = proj_get(),
    given = given,
    family = family,
    email = email,
    role = role,
    comment = comment
  )

  invisible()
}

Main problem is that it mangles all existing formatting.

Wow, there's a desc package now? that's awesome, wish I'd seen that sooner.

The use_author() looks very promising to me!

Naively, seems like some logic to update existing authors without totally mangling the DESCRIPTION would be possible? (I'm sure @sckott would love to be able to script a way to add ORCIDs to all his existing DESCRIPTION entries :wink:)

Does anyone care to point out very low-hanging fruit here? A release is imminent. My assessment is that this should wait.

@hadley 's use_author() function above looks nice to me.

I haven't looked at the internals of how desc::desc_add_author handles duplicates vs updates, but in any event that would be an issue for the desc package.

I have opened a related PR in desc https://github.com/r-lib/desc/pull/70 It exposes an orcid argument in the add/get authors functions.

desc::add_me uses whoami for "this is my name, email" and in my PR I'm adding support for an ORCID_ID environment variable.

Maybe usethis could also look for ORCID_ID when creating a new DESCRIPTION?

related to #432 maybe

@maelle would you be interested in putting together a PR improve ORCID support? I don't have much of a sense for what is needed, so I'd love to get some help 馃槃

Ok will do! what comes to mind is not much:

  • adding default ORCID field to the default template for authors
  • ~using ORCID from the ORCID_ID environment variable if present, for the aut+cre role , or from the custom default author in usethis./devtools.options (should already work), to fill the field when creating a package.~ not a good idea
  • updating examples including in the setup article.
  • add a pointer in the docs to desc (convenience) functions maybe, that all support ORCID? Rather than wrappers which would be outside the scope of this issue. 馃

I will take a look at this

There's an open PR #530 that doesn't add a ton though

Ah ok - this was just tagged help-wanted - I will find another one to work on

Thanks to #530 (merged) we now model how to include one's ORCID id in the usethis-related options in .Rprofile. Which is as much support as we provide for anything re: customization via options.

PRs related to better author support here and/or in desc (where it probably belongs) remain welcome, but I don't see any burning issue for us to address here.

Was this page helpful?
0 / 5 - 0 ratings