Skip to content

Commit dc73e90

Browse files
committed
fix role highlighting in NL workflow
1 parent fc1caf8 commit dc73e90

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

nl/workflow.md

Lines changed: 8 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -12,11 +12,11 @@ You are probably doing fine even if you digress from this documentation.
1212
## Steps
1313

1414
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
15-
1. **Authors** send their request for a CODECHECK to project e-mail address [[email protected]](mailto:[email protected])
16-
1. The CodecheckNL project team accepts the request for the workshop or advises to follow the normal community workflow (see above)
17-
1. During the workshop, codecheckers download materials or clone the a repository
18-
1. The workshop codecheckers create a new directory in their working environment where all new files go, and start documenting the ongoing codecheck; exact form of codechecking procedure and form of documentation vary greatly, but there are some tools, such as an R package to automate some steps, including a Rmd template; all of that is optional, as long as the final report contains the mandatory information
19-
1. During codecheck, the workshop codecheckers can ask the authors (if present at the workshop) in case of encountered problems, keeping in mind the general Codecheck philosophy (especially “the codechecker records but does not fix” – unless it is a very trivial bug like pathnames)
20-
1. The codecheckers summarize the process and outcome in a report and bundle it with all input and output files; this workshop codecheck bundle is then shared with the CodecheckNL 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))
21-
1. The CodecheckNL project team checks the bundle and report, and together with the workshop codecheckers, revise where necessary; once ready, either the CodecheckNL project team or a corresponding codechecker upload the file on Zenodo or OSF, and [optionally] adds a pull request to original repository for the Codecheck badge
22-
1. The CodecheckNL project team adds the new codecheck to the registry.
15+
1. **Authors** send their request for a CODECHECK to project e-mail address <[email protected]>
16+
1. The **CHECK-NL project team** accepts the request for the workshop or advises to follow the normal community workflow (see above)
17+
1. During the workshop, **codecheckers** download materials or clone the a repository
18+
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
19+
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)
20+
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))
21+
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
22+
1. The **CHECK-NL project team** project team adds the new codecheck to the registry.

0 commit comments

Comments
 (0)