Improve GitHub workflow guidance

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

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.
 

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. 

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.