Add co-authoring commits section to code-review

code-review.qmd

@@ -24,3 +24,15 @@ It is left to the maintainer or one of the authors of a package to merge the PR
 Code review can be skipped in cases when the package maintainer or authors makes minimal changes, these include, but are not limited to: not touching user-facing functions, only changing package accessories (e.g. Github actions) or minor documentation fixes. In these cases a "Merge without waiting for requirements to be met (bypass branch protections)" option can be ticked and the PR can be merged. For more information on merging see the [Standards for branching and merging](git-branching-merging.qmd).
 
 If suggested changes fall outside the scope of the PR, utilise Github's feature of generating issues from PR comments. Clicking the ellipsis in the PR comment and selecting "Reference in new issue" will open an issue with reference to the PR.
+
+## Recognising contributions in reviews
+
+GitHub's feature of suggestions that can be directly committed within the PR are a useful feature that we recommend using for relatively small changes to the code. In most circumstances, these can be directly committed to the feature branch in the PR. GitHub attributes [co-authorship to those that suggested the change and who commited the change](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request#applying-suggested-changes). This is a nice feature that [enables easy recognition of contributions.](contribution-acknowledgements.qmd)
+
+However, in a scenario where the suggested change cannot be commited to the feature branch in the PR, and instead is incorporated in a different feature branch, the suggestion should still be acknowledged. This is where manually specifying [commit coauthors](https://github.blog/2018-01-29-commit-together-with-co-authors/) can help. When using the suggestions of a collaborator, include two empty lines after the commit message and use the phrase `Co-authored-by:` followed by the collaborator's GitHub name and email (this may be a Github no-reply email). See <https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors> for details.
+
+::: {.callout-tip title="Read more about this principle in application"}
+
+If a collaborator makes a substantial contribution to the package make sure that they are [recognised in the DESCRIPTION](contribution-acknowledgements.qmd#contributor-vs.-author-distinction).
+
+:::

contribution-acknowledgements.qmd

@@ -37,6 +37,8 @@ Drawing a parallel with academic publishing: contributors (`"ctb"`) are more aki
 
 Contributors can also be recognized by [adding them as commit authors or co-authors](https://github.blog/2018-01-29-commit-together-with-co-authors/). This practice is particularly appropriate for minor contributions, such as typo fixes, code formatting improvements, or small documentation updates that do not warrant an addition to the list of authors in the package `DESCRIPTION` file. By including contributors as commit authors or co-authors, their contributions are acknowledged within the version control history. This approach provides visibility and recognition for their specific contributions.
 
+Co-authoring commits manually requires the contributors username and email. If you do not have the collaborators email address, one way to find it is to navigate on GitHub to a commit they have authored. The URL of the commit should follow the form: `https://github.com/<gh_username>/<repo_name>/commit/<commit_sha>`. Once on this page, add `.patch` to the end of the URL and their email should be given. As stated above, this can be a GitHub no-reply email.
+
 ### In the package changelog
 
 Similarly, each change should be documented as a bullet in `NEWS.md`. It is then good practice to document who created the change and link to the relevant pull request. For example: