add template files for word processors, small typos and edits

Author: nuest

.markdownlint.json

@@ -15,7 +15,9 @@
             "strong",
             "iframe",
             "br",
-            "script"
+            "script",
+            "details",
+            "summary"
         ]
     },
     "MD013": false,

guide/community-workflow-codechecker.md

@@ -16,8 +16,8 @@ Now it's your turn.
 1. Accept codechecking invitation by commenting on the issue
 1. Create a repository in the CODECHECK GitHub organization, either by forking existing repository or creating new one and uploading materials
 1. Create a new directory in that repository where all new files will go
-1. Create a new document to write the CODECHECK certificate and _start documenting the ongoing codecheck now_
-   The exact form of  a codechecking procedure and form of documentation vary greatly, but there are some tools, such as [an R package](https://github.com/codecheckers/codecheck) to automate some steps, including [an Rmd template](https://github.com/codecheckers/codecheck/blob/master/inst/extdata/templates/codecheck/codecheck.Rmd); all of that is optional, as long as the final certificate contains the mandatory information
+1. Create a new document to write the CODECHECK certificate and _start documenting the ongoing codecheck now_;
+   the exact form of  a codechecking procedure and form of documentation vary greatly, but there are some tools, such as [an R package](https://github.com/codecheckers/codecheck) to automate some steps, including [an Rmd template](https://github.com/codecheckers/codecheck/blob/master/inst/extdata/templates/codecheck/) and word processor templates in [.odt](/guide/templates/CODECHECK_report_template.odt) and [.docx](/guide/templates/CODECHECK_report_template.docx) formats; all of that is optional, as long as the final certificate contains the mandatory information
 1. Open the manuscript and follow the instructions to reproduce a workflow
 1. During the CODECHECK, contact the authors in case of problems; keep in mind the general [CODECHECK principles](/project/#the-codecheck-principles), especially “the codechecker records but does not fix” – unless it is a very trivial bug like pathnames; the authors can provide updated versions of code and documentation; however, the entire procedure should not be much more time-intensive than a normal peer review of a paper and not involve more than a few code revisions; the codechecker can always stop the process after a reasonable effort and close the issue as not successfully reproduced.
 1. Summarize the process and outcomes in your certificate and upload it as PDF to [Zenodo](https://zenodo.org/) or [OSF](https://osf.io/); add edited files and intemediary as well as output files as you see fit; the certifiate must at least contain the information on who checked what and how; the ambition should be to document for future self and other researchers; have a look at the available certificates.
@@ -49,7 +49,7 @@ Some further tips:
 - Reach out to fellow codecheckers in the [public discussion forum](https://github.com/orgs/codecheckers/discussions) if you face any problems.
 - A familiarity with `make` is helpful to provide an easy entrypoint and build up useful code snippets for your CODECHECKs, see <https://book.the-turing-way.org/reproducible-research/make> and <https://swcarpentry.github.io/make-novice/reference>
 
-## CODECHECK steps
+### CODECHECK steps
 
 1. Comment on the issue in the CODECHECK register repository to notify author and editor that you're accepting (and starting) the CODECHECK.
 1. Fork the author's repository to the codecheckers GitHub.com or GitLab.com organisation, or, if the code is not on GitHub/GitLab, create a new repository with the naming scheme `Lastname-YYYY` using the family name of the corresponding author. Please take care to follow the terms and conditions of the workspace's licenses; stop your CODECHECK if the licensing is unclear and contact the author to fix the documentation.
@@ -66,7 +66,9 @@ Some further tips:
         - Make the repository [Binder-ready](https://mybinder.readthedocs.io/); put all Binder-related files into `.binder/` directory to separate them from the author's content.
     1. **Write the CODECHECK certificate** and save it as a PDF file named **`codecheck.pdf`** in the check directory.
       The certificate should cover at least _WHO_ checked _WHAT_, and _HOW_.
+      There are not strict requirements on the form, but you're welcome to use our word processor templates in [.odt](/guide/templates/CODECHECK_report_template.odt) and [.docx](/guide/templates/CODECHECK_report_template.docx) formats or the [.Rmd template from our R package](https://github.com/codecheckers/codecheck/blob/master/inst/extdata/templates/codecheck/).
       Imagine the certificate as a reminder for future you so you will be to re-check the workflow in two years time - what help would you need to do that?
+      There is no need to document every detailed step if that is not helpful for you.
       Include a _full citation of the certificate_, because your CODECHECK is a valuable contribution to science (see below for reserving the DOI).
       Take a look at the [example CODECHECKs](/guide/community-workflow-overview#examples) for existing certificates to serve as templates.
     1. **Optional certificate sections** depending on interest, time, and skills:

guide/templates/CODECHECK_report_template.docx

@@ -51,7 +51,7 @@ The British Neuroscience Association (BNA) have awarded the 2024 Team Credibilit
 
 ### 2024-03 | Dutch Research Council (NWO) supports CODECHECK 🇳🇱
 
-We are happy to announce a one-year grant from the Dutch Research Council (NWO) to support Codecheck activities in the Netherlands.
+We are happy to announce a one-year grant from the Dutch Research Council (NWO) to start various CODECHECK activities in the Netherlands.
 The project is led by Frank Ostermann (University of Twente) with colleagues from Delft and Groningen.
 [Further details](/nl/).
 

guide/templates/CODECHECK_report_template.odt

@@ -4,19 +4,20 @@ title: CODECHECK community workflow for CHECK-NL
 ---
 
 The following steps are required to complete a CODECHECK as part of a workshop organised by [CHECK-NL](/nl/).
-See also the [CODECHECK community workflow overview](/guide/community-workflow-overview) for a broader approach.
+See also the [CODECHECK community workflow overview](/guide/community-workflow-overview) for more details, partly because that approach focuses on online collaboration.
+
 Before you start, note that every CODECHECK is unique, just as the associated research article.
 Reach out to fellow codecheckers in the [public CODECHECK discussion forum](https://github.com/codecheckers/discussion/issues) if you face any problems, or use the [internal team discussion](https://github.com/orgs/codecheckers/teams/codecheckers) if you need to consult in private.
-You are probably doing fine even if you digress from this documentation.
+You are probably doing fine even if you digress from this documentation!
 
 ## Steps
 
-1. **Authors** create a pre-producible workflow: all data and code, plus a readme file detailing the content, a manifest file detailing the [output CODECHECK configuration file](/spec/config/1.0/), and a license file; this is ideally bundled in a single repository or archive file and accompanied by a (pre-published) paper
-1. **Authors** send their request for a CODECHECK to project e-mail address <[email protected]>
-1. The **CHECK-NL project team** accepts the request for the workshop or advises to follow the normal community workflow (see above)
-1. During the workshop, **codecheckers** download materials or clone the a repository
-1. The **codecheckers** create a new directory in their working environment where all new files go, and start documenting the ongoing codecheck; the exact form of codechecking procedure and form of documentation vary greatly, but there are some tools, such as an [R package](https://github.com/codecheckers/codecheck) to automate some steps, including a [Rmd template](https://github.com/codecheckers/codecheck/tree/master/inst/extdata/templates/codecheck); all of that is optional, as long as the final report contains the mandatory information
-1. During codecheck, the **codecheckers** can ask the **authors** (if present at the workshop) in case of encountered problems, keeping in mind the [CODECHECK principles](/project#the-codecheck-principles) (especially “the codechecker records but does not fix” – unless it is a very trivial bug like pathnames)
-1. The **codecheckers** summarize the process and outcome in a report - the CODECHECK certificate - and bundle it with all input and output files; this workshop codecheck bundle is then shared with the **CHECK-NL project team** via email or repository; the report should at least contain the information on who checked what and how; document for future self and other researchers; have a look at the available reports; most contain also optional information (compare [CODECHECK community workflow guide](/guide/community-workflow-overview))
-1. The **CHECK-NL project team** checks the bundle and report, and together with the workshop codecheckers, revise where necessary; once ready, either the **CHECK-NL project team** or the **codechecker** upload the file on Zenodo or OSF, and [optionally] adds a pull request to original repository for the Codecheck badge
+1. **Authors** create a pre-producible workflow: all data and code, plus a readme file detailing the content, a manifest file detailing the [output CODECHECK configuration file](/spec/config/1.0/), and a license file; this is ideally bundled in a single repository or archive file and accompanied by a (pre-published) paper.
+1. **Authors** send their request for a CODECHECK to project e-mail address <[email protected]>.
+1. The **CHECK-NL project team** accepts the request for the workshop or advises to follow the normal community workflow (see above).
+1. During the workshop, **codecheckers** download materials or clone the a repository and work on their computers.
+1. The **codecheckers** create a new directory in their working environment where all new files go, and start documenting the ongoing codecheck; the exact form of codechecking procedure and form of documentation vary greatly, but there are some tools, such as an [R package](https://github.com/codecheckers/codecheck) to automate some steps, including an [Rmd template](https://github.com/codecheckers/codecheck/tree/master/inst/extdata/templates/codecheck); all of that is optional, as long as the final report contains the mandatory information; the templates in [.odt](/guide/templates/CODECHECK_report_template.odt) and [.docx](/guide/templates/CODECHECK_report_template.docx) formats should get you going quickly.
+1. During codecheck, the **codecheckers** can ask the **authors** (if present at the workshop) in case of encountered problems, keeping in mind the [CODECHECK principles](/project#the-codecheck-principles) (especially “the codechecker records but does not fix” – unless it is a very trivial bug like pathnames).
+1. The **codecheckers** summarize the process and outcome in a report - the CODECHECK certificate - and bundle it with all input and output files; this workshop codecheck bundle is then shared with the **CHECK-NL project team** via email or repository; the report should at least contain the information on who checked what and how; document for future self and other researchers; have a look at the available reports; most contain also optional information (compare [CODECHECK community workflow guide](/guide/community-workflow-overview)).
+1. The **CHECK-NL project team** checks the bundle and report, and together with the workshop codecheckers, revise where necessary; once ready, either the **CHECK-NL project team** or the **codechecker** upload the file on Zenodo or OSF, and [optionally] adds a pull request to original repository for the CODECHECK badge.
 1. The **CHECK-NL project team** project team adds the new codecheck to the registry.

index.md

@@ -29,7 +29,7 @@ The fact that such a check is conducted and the communication between codechecke
    <details>
    <summary>More about this principle...</summary>
    The value of performing a CODECHECK is comparable to that of a peer review, and it may require a similar amount of time. Therefore, the codechecker’s activity should be recorded, ideally in the published paper. The public record can be realised by publishing the certificate in a citable form (i.e., with a DOI), by listing codecheckers on the journal’s website or, ideally, by publishing the checks alongside peer review activities in public databases.
-   <em>Codechecks are an excellen opportunity to involve early career researchers (ECRs) or research software engineers (RSEs) in peer review.</em>
+   <em>Codechecks are an excellent opportunity to involve early career researchers (ECRs) or research software engineers (RSEs) in peer review.</em>
    </details>
 1. <span class="principle">Workflows must be auditable.</span>
    <details>