Lisez-le en : Español.

Lisez-le en : Português.

Les conseils de rOpenSci Software Peer Review sont rassemblés dans un livre en ligne qui ne cesse de s’améliorer ! Cet article de blog résume les nouveautés de notre Dev Guide 1.0.0, avec toutes les modifications répertoriées dans le journal des modifications.

Maintenant disponible en portugais !

Notre guide est désormais trilingue (anglais, espagnol, portugais) !

Découvrez-en davantage sur l’impressionnant projet de traduction en portugais, initié et alimenté par nos membres lusophones dans notre article de blog.

Le projet de traduction et la maintenance multilingue continue utilisent notre package babelquarto pour rendre les livres et sites Web Quarto multilingues. Il a récemment été évalué par Ella Kaye et João Granja-Correia.

Nous travaillons activement sur notre package babeldown pour créer et mettre à jour des traductions à l’aide de l’API DeepL.

Dans le guide de développement lui-même, des outils utiles pour l’internationalisation forfaits sont mentionnés : potools, le package expérimental rhelpi18n, sélection d’une langue pour un site Web pkgdown.

Mises à jour des politiques

Nous avons apporté quelques modifications aux politiques et à la portée de rOpenSci :

Guide de l’éditeur, guide de l’auteur et guide du réviseur

Les guides qui vivent dans notre guide. 😸

L’ensemble du guide de l’éditeur a été restructuré pour suivre le flux typique des soumissions et pour mieux expliquer comment utiliser le tableau de bord d’évaluation des logiciels. Nous avons ajouté une section sur les défis et documenté comment mettre le système en vacances (ce que nous faisons généralement au cours de la nouvelle année).

De même, nous avons amélioré l’organisation et le contenu du guide de l’auteur (merci à Alec Robitaille et Joan Maspons).

Dans le guide du réviseur, nous avons supprimé le lien externe vers le guide Mozilla Review, qui n’est plus maintenu (l’une de nos premières sources de conception pour l’évaluation par les pairs) au profit d’éléments énumérés explicitement.

Meilleures pratiques d’emballage

Dans le guide de packaging (un autre guide dans le guide !), nous avons ajouté des conseils pour choisir des exemples d’ensembles de données. De plus, nous avons créé une section pour les packages encapsulant des logiciels externes. La section sur les licences exige désormais explicitement de reconnaître les auteurs du code groupé. Enfin, la section sur les dépendances recommande de vérifier l’état de développement des dépendances.

Le livre entier mentionne désormais Air CLI à chaque fois qu’il mentionne le package styler, car Air peut être considéré comme le successeur de styler.

Dans le chapitre sur l’évolution des packages, nous avons ajouté des conseils sur la dépréciation donnéeset a expliqué les inconvénients de renommer un package largement utilisé.

Conseils pour les tests

Nous avons mis à jour nos conseils de test avec

Documentation du paquet

Grâce à un merci particulier à Alasdair Warwick, nous avons amélioré la documentation 😉 de notre système de création de documentation, notamment :

Nous avons également clarifié différentes stratégies pour documenter les fonctions internes, grâce à Claudiu Forgaci.

Métadonnées et informations sur les packages

Nous avons documenté d’autres façons de remercier les contributeurs :

Conclusion

Dans cet article, nous avons résumé les modifications apportées à la dernière version de notre livre « Packages rOpenSci : développement, maintenance et examen par les pairs ». Nous sommes reconnaissants pour toutes les contributions qui ont créé cette version. Nous travaillons déjà sur la prochaine version. N’hésitez pas à nous aider à le façonner en ouvrant un numéro !

En rapport