lunes, 2 de marzo de 2026 From rOpenSci (https://ropensci.org/es/blog/2026/03/02/r_open_sci_dev_guide_1_0_0_triling%C3%BCe_y_mejorada/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
Las orientaciones de rOpenSci para realizar la revisión de software por pares se recopilan en un libro en línea ¡que sigue mejorando! Este artículo resume las novedades de nuestra Guía de Desarrollo 1.0.0, incluyendo todos los cambios enumerados en la sección de registro de cambios.
¡Nuestra guía es ahora trilingüe (inglés, Español, Portugués)!
Si quieres saber más sobre el impresionante proyecto de traducción al portugués, iniciado e impulsado por las personas lusófonas que integran nuestra comunidad, visita nuestro artículo sobre el tema.
El proyecto de traducción y mantenimiento multilingüe en curso utiliza nuestro paquete babelquarto para producir libros y sitios web Quarto multilingües. Recientemente revisado por pares por Ella Kaye y João Granja-Correia.
Estamos trabajando activamente en nuestro paquete babeldown para crear y actualizar traducciones utilizando la API DeepL.
En la guía de desarrollo también se mencionan herramientas útiles para internacionalizar paquetes: potools el paquete experimental rhelpi18n y la selección de un idioma para un sitio web pkgdown.
Hemos realizado algunos cambios en las políticas y el alcance de la revisión por pares:
Nueva categoría para Herramientas internas y de revisión por pares de rOpenSci.
Actualizaciones de la categoría de recuperación de datos.
Nueva regla explícita para presentar un paquete a la vez.
Nuevo requisito para no llamar a la rama por defecto “master”.
Eliminado el requisito de utilizar un codemeta.json ya obsoleto. Codemeta sigue siendo utilizado y desarrollado activamente pero hemos descubierto que es redundante con otros metadatos y Codemeta puede generar estos datos según sea necesario a partir de archivos DESCRIPTION.
Las guías que viven en nuestra guía :smile
La guía para el equipo editorial se ha reestructurado para seguir el flujo típico de los envíos,
y para explicar mejor cómo utilizar el panel de revisión de software.
Hemos añadido una sección sobre retos y hemos documentado cómo poner el sistema en “modo vacaciones” (lo que solemos hacer durante el periodo de las fiestas de fin de año).
Asimismo, mejoramos la organización y el contenido del guía para autores y autoras (gracias a Alec Robitaille y Joan Maspons).
En la guía de revisión eliminamos el enlace a la guía de revisión de Mozilla (una de nuestras primeras fuentes de diseño para nuestro proceso) porque ya no se mantiene y enumeramos los elementos explícitamente.
En la guía de desarrollo de paquetes (¡otra guía dentro de la guía!), añadimos orientaciones para elegir conjuntos de datos de ejemplo. Además, agregamos una sección para paquetes que incluyen software externo. La sección sobre licencias exige ahora explícitamente que se mencione a las personas autoras del código incluido. Por último, pero no por ello menos importante, la sección sobre dependencias recomienda comprobar el estado de desarrollo de las dependencias.
Todo el libro ahora menciona el CLI de Air cada vez que menciona el paquete styler, ya que Air puede considerarse su sucesor.
En el capítulo sobre la evolución de los paquetes, añadimos orientaciones sobre la eliminación de datos y se explican los inconvenientes de renombrar un paquete muy utilizado.
Hemos actualizado nuestras orientaciones sobre pruebas (test) con
Agradecimientos especiales a Alasdair Warwick hemos mejorado la documentación 😉 de nuestro sistema de creación de documentación, entre otras cosas:
También aclaramos diferentes estrategias para documentar funciones internas gracias a Claudiu Forgaci.
Hemos documentado más formas de reconocer a quienes colaboran:
en el capítulo sobre autoría agregando el ID del Registro de Organismos de Investigación (ROR);
en el capítulo sobre colaboración con el paquete allcontributors.
Este es un resumen de los cambios de la última versión de nuestro libro “Paquetes rOpenSci: Desarrollo, mantenimiento y revisión por pares”. Agradecemos todas las contribuciones que han dado lugar a esta publicación. Ya estamos trabajando en la próxima versión. No dudes en ayudarnos a darle forma abriendo un issue ¡!
