diff --git a/NEWS.md b/NEWS.md index 55130c3f5..2a5d735ae 100644 --- a/NEWS.md +++ b/NEWS.md @@ -1 +1 @@ -https://github.com/ropensci/dev_guide/blob/master/appendix.Rmd#news +https://github.com/ropensci/dev_guide/blob/main/booknews.Rmd diff --git a/booknews.Rmd b/booknews.Rmd index 838d2780a..dae4943f4 100644 --- a/booknews.Rmd +++ b/booknews.Rmd @@ -2,13 +2,17 @@ ## dev (0.9.0) +- 2022-07-04, Add resources around GitHub workflows (#479, `@maurolepore`). + - 2023-02-14, update instructions for CITATION to reflect new CRAN policies (#604, #609) - 2023-02-14, add package maintainer cheatsheet (#608). - 2023-01-25, add Mastodon as social media (#592, by @yabellini). -- 2023-01-20, fix small formating error (#590 by @eliocamp). +- 2023-01-25, add Mastodon as social media (#592, by `@yabellini`). + +- 2023-01-20, fix small formating error (#590 by `@eliocamp`). - 2022-11-22, mention shinytest2 near shinytest. diff --git a/maintenance_collaboration.Rmd b/maintenance_collaboration.Rmd index 65964ddc5..a1a46a287 100644 --- a/maintenance_collaboration.Rmd +++ b/maintenance_collaboration.Rmd @@ -105,20 +105,26 @@ A possible model for onboarding collaborators is provided by Jim Hester in [his If your problem is _recruiting_ collaborators, you can post an open call like Jim Hester's [on Twitter](https://twitter.com/jimhester_/status/997109466674819074), [GitHub](https://github.com/jimhester/lintr/issues/318), and as an rOpenSci package author, you can ask for help in rOpenSci slack and ask rOpenSci team for ideas for recruiting new collaborators. -### Working with collaborators (including yourself) {#gitflow} +### Working with collaborators (including yourself) {#git-workflow} [Branches](https://happygitwithr.com/git-branches.html) are cheap. Use them extensively when developing features, testing out new ideas, fixing problems. One of the branches is the default / main branch, where, if you follow [trunk-based development](https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development), you "merge small, frequent updates". See also [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) and [GitLab flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html) docs. -You might want to pair the frequent incrementing of version numbers (in `DESCRIPTION`). +You might want to frequently increment version numbers (in `DESCRIPTION`). One particular aspect of working with collaborators is reviewing pull requests, with some useful guidance in: -* [The Art of Giving and Receiving Code Reviews (Gracefully), by Alex Hill](https://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/) -* [GitHub documentation about PR reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) +* [The Art of Giving and Receiving Code Reviews (Gracefully), by Alex Hill](https://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/); +* [GitHub documentation about PR reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews). + +You might want to tinker with your GitHub repository settings to, for instance, [require pull request reviews before merging](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging=). +See also GitHub docs about ["code owners"](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). For making and reviewing pull requests we recommend [exploring usethis functions](https://usethis.r-lib.org/articles/pr-functions.html). +For your "git remote" setup refer to [happy git with r](https://happygitwithr.com/common-remote-setups.html). +See also [Useful Git patterns for real life](https://happygitwithr.com/workflows-intro.html) in the same book. + ### Be generous with attributions {#attributions} If someone contributes to your repository consider adding them in DESCRIPTION, as contributor ("ctb") for small contributions, author ("aut") for bigger contributions. Traditionally when citing a package in a scientific publication only "aut" authors are listed, not "ctb" contributors; and on `pkgdown` websites only "aut" names are listed on the homepage, all authors being listed on the authors/ page. diff --git a/maintenance_collaboration.es.Rmd b/maintenance_collaboration.es.Rmd index b69ee10a2..e9867060b 100644 --- a/maintenance_collaboration.es.Rmd +++ b/maintenance_collaboration.es.Rmd @@ -110,7 +110,7 @@ Jim Hester ofrece un posible modelo de incorporación de miembros de equipo en [ Si tu problema es *reclutar* nuevas personas, puedes publicar una convocatoria abierta como la de Jim Hester [en Twitter](https://twitter.com/jimhester_/status/997109466674819074), [GitHub](https://github.com/jimhester/lintr/issues/318) y, como responsable de un paquete de rOpenSci, puedes pedir ayuda en el Slack de rOpenSci y solicitar al equipo de rOpenSci ideas para reclutar ayuda. -### Trabajar con otras personas (y incluyendo tú en el futuro) {#gitflow} +### Trabajar con otras personas (incluyendo tú en el futuro) {#git-workflow} [Las *branches*](https://happygitwithr.com/git-branches.html) son baratas. Utilízalas mucho cuando desarrolles funciones, pruebes nuevas ideas o arregles problemas. @@ -124,8 +124,15 @@ Pueden ver algunas guías útiles en: - [*The Art of Giving and Receiving Code Reviews (Gracefully)* (El arte de dar y recibir revisiones de código (con elegancia)), por Alex Hill](https://www.alexandra-hill.com/2018/06/25/the-art-of-giving-and-receiving-code-reviews/) - [Documentación de GitHub sobre revisiones de PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/about-pull-request-reviews) +Puedes modificar la configuración de tu repositorio de GitHub, +por ejemplo [requeriendo revisiones de solicitudes de cambio antes de aceptarlas e incorporarlas](https://docs.github.com/es/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches#require-pull-request-reviews-before-merging). +También puedes consultar la documentación [acerca de propiedad sobre código](https://docs.github.com/es/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners). + Para hacer y revisar *pull requests* recomendamos [explorar las funciones del paquete usethis](https://usethis.r-lib.org/articles/pr-functions.html). +Para tu configuración "git remote" consulta [_Happy Git with R_](https://happygitwithr.com/common-remote-setups.html). +También es útil la sección [Useful Git patterns for real life](https://happygitwithr.com/workflows-intro.html) en el mismo libro. + ### Atribuye con generosidad {#attributions} Si una persona contribuye a tu repositorio, considera añadirla en el archivo DESCRIPTION, con el rol de contribución ("ctb") para pequeñas contribuciones o autoría ("aut") para contribuciones mayores.