¿Debería existir?

• ¿Este código le sirve a alguien más que a mi?
• ¿La idea es nueva o puede haber un paquete que ya haga o mismo que usted piensa hacer? Si es así, ¿qué trae de nuevo su implementación, ej. implementación amigable de usuario? Ej. keras y kerasR.
• Si ya existe una librería similar, ¿debería trabajar solo o más bien ayudarle a mejorar al desarrollador original la librería ya creada? Ej. rtweet y twitteR

¿Qué debería tener su paquete exactamente?

1. Hacerlo compatible con el flujo de trabajo de sus usuarios.

2. No ser demasiado ambicioso. Por ejemplo, ¿desea tener un método gráfico específico para su salida, o puede confiar en que sus usuarios usen por ejemplo ggplot2, simplemente dándoles un ejemplo de cómo hacerlo en una viñeta? De hecho, es parte de la filosofía de Unix: “pequeñas piezas construidas una encima de la otra”. Esto le ahorrará tiempo y le permitirá concentrarse en lo importante.

Una vez que haya decidido todo esto, tal vez esboze una lista de tareas pendientes. Si ya está familiarizado con Github, puede tener un issue por item, o incluso aprovechar la función de hitos de Github. No es necesario tener un plan maestro para toda la vida útil de su paquete, porque uno puede esperar que sus usuarios también influyan en las funciones futuras, y bueno, usted seguirá haciéndose más inteligente a medida que pase el tiempo y las ideas seguirán fluyendo.

Si desea trabajar en su paquete como equipo, deje en claro los roles desde el principio, por ejemplo, ¿Quién será el capo y quiénes sus gregarios…

¿Cómo llamar a su paquete en R?

Se aconsejan nombres en minúsculas recomendados por rOpenSci, porque de esta manera su usuario no necesita recordar dónde están las letras mayúsculas (sí, es una recomendación divertida de una organización llamada rOpenSci).

Se recomienda verificar el nombre de su paquete a través del paquete available que le dirá si es válido, está disponible en los lugares de paquetes habituales y también si tiene algún significado no deseado.

Libros

1. Libro de Hadley Wickham
2. Mastering Software Development in R
3. Escribiendo extensiones en R
4. rOpenSci packaging guide

Blogs

1. Writing an R package from scratch
2. Guía ilustrada para desarrollo de paquetes en R

MOOCS

6. Mastering Software Development in R Specialization

Haga código abierto

• Mantenga la filosofía del mismo R que es de código abierto

• Eso facilita la depuración y juega en favor de la calidad de su paquete

• Se recomienda Github pero existen Gitlab, svn, etc.

• Si se la juega con Github:

  1. Este capítulo del libro de Wickham

  2. La página de Jenny

  3. Si las cosas se ponen mal

Póngalo en plataformas oficiales

• CRAN

• Bioconductor

Tenga en cuenta la confianza

• Use devtools()

Enlácelo

• En la DESCRIPTION de su paquete, indique la URL del repositorio donde aloja su paquete al igual que el link de los issues y reporte de bugs

• Si su paquete está en Github:

  1. Cree una versión y agregue información sobre su actualización
  2. Los usuarios de su paquete pueden estar actualizados de las versiones de su paquete si usan Sibbell
  3. Póngale las insignias del CRAN que funciona más o menos así

Añádale un estilo a su código

Dele un estilo a su código para futuros lectores, que será usted mismo en un futuro, colaboradores y usuarios curiosos. Si su código es bonito, será más fácil para ellos concentrarse en su contenido.

• Use lintr para análisis estático del código.
• Use styler para poner su paquete más bonito.

Reciba consejos automáticos sobre su paquete

Instale y ejecute goodpractice para asesoramiento que incluye funciones y sintaxis a evitar, la estructura del paquete, la complejidad del código, el formato del código, etc.

Elimine errores tipográficos

Utilice la función devtools::spell_check(). Los errores tipográficos en la documentación no son el fin del mundo, pero pueden molestar al usuario y no es difícil eliminarlos gracias a esta herramienta, así que hágalo cuando tenga oportunidad.

Todas estas herramientas le proporcionan una lista de cosas para cambiar. Esto significa que crean una lista de cosas para hacer sin necesidad de pensar demasiado, así que si está un poco cansado pero quiere mejorar su paquete, esto será de mucha utilidad.

Documentación

Documente sus parámetros, funciones, agregue ejemplos y también escriba viñetas. Al menos una viñeta mostrará a los usuarios cómo interactúan las diferentes funciones de su paquete.

Una vez haya escrito todas las partes de la documentación, cree un sitio web para su paquete usando pkgdown. Este tutorial es excelente.

Programación amigable

“A la larga, el buen diseño gana, porque hace que sus adeptos sean más productivos y más impactantes, por lo tanto, se extiende más rápido que el diseño hostil al usuario. Un buen diseño es contagioso”.

1. Tenga mensajes de error y advertencia que sean fáciles de entender. Por ejemplo, si se comunica con una API, entonces traduzca los errores http.

2. Verifique las entradas. Por ejemplo, si un parámetro proporcionado a una función debe ser un número positivo, verifíquelo y, de no ser así, devuelva un mensaje de error amistoso.

3. Elija un buen esquema de nombres que permita a los usuarios recordar más fácilmente los nombres de las funciones. Puede elegir tener un prefijo para todas las funciones de tu paquete, lo cual es recomendado por rOpenSci.

Promociónelo

Si es científico, puede escribir un documento sobre su paquete y publicarlo en un journal en su campo. Por cierto, cuando usa R y paquetes en un documento, no olvide citarlos (utilizando el resultado de citation(), por ejemplo) para reconocer su utilidad y ayudar a sus autores a sentir que su trabajo es valioso (además si son académicos que tienen su trabajo citado es bastante crucial para su avance profesional).

Revíselo

Como científico, está acostumbrado a tener revisión por pares. En general, si envía un documento sobre su paquete, su documento será revisado más que su paquete, ¡pero en realidad puede obtener los beneficios de la revisión por pares para su paquete. Esta es una manera fantástica de mejorar la calidad y la facilidad de uso de su paquete.

1. No necesita nada formal, tal vez puede preguntarle a alguien que conoce y que, por ejemplo, podría ser un usuario de su paquete. Puede pedirle que revisen el código o su documentación, o ambos, según sus habilidades.

2. The R Journal le pide a los revisores de los documentos que lean el paquete, al igual que The Journal of Statistical Software. Dicho esto, necesitará escribir un documento completo para acompañar su paquete, que tal vez sea algo que no quieres.

3. El Journal of Open Science Software, JOSS les pide a los revisores que verifiquen algunos puntos en su paquete y que escriban un documento muy mínimo sobre su paquete. El proceso de revisión es mínimo pero, de todas formas, puede obtener comentarios útiles.

4. En rOpenSci revisan los paquetes que se ajustan a sus categorías. Su paquete será revisado por dos personas. Ellos tienen una asociación con el Journal of Open Source Software de modo que si su paquete se adapta a ambos lugares, la revisión en JOSS será muy fácil después de las revisiones de rOpenSci.

Haga su repo un lugar agradable

Otra forma de mejorar la calidad de su paquete y hacerlo más fácil de usar es tranquilizar a las personas cuando tienen una pregunta, un informe de error o una sugerencia de mejora. Agregar un código de conducta (use devtools::use_code_of_conduct como punto de partida) .

Puede agregar una insignia de estado para su repositorio, de modo que cualquier visitante pueda ver de un vistazo si su paquete aún se encuentra en una etapa de desarrollo inicial.

Si las personas realmente comienzan a contribuir con el paquete, intente ser generoso con los agradecimientos. Una razón egoísta es que motivará a las personas a seguir contribuyendo a su paquete. Una razón menos egoísta es que hace que toda la comunidad R sea más acogedora para los nuevos contribuyentes.

Análisis de paquetes

Si tiene curiosidad, puede hacerse una idea de la cantidad de descargas de su paquete a través del paquete de cranlogs. Utilizándolo, puede comparar la popularidad de su paquete con paquetes similares y verificar si hubo un pico después de un que ha dado, por ejemplo.

De forma similar, si su repositorio de paquetes está alojado en Github, usando el paquete gh puede hacer análisis similares, mirando el número de estrellas a lo largo del tiempo, por ejemplo.