Info on the peer review process + pull request template #188
Conversation
|
|
||
| > [!NOTE] | ||
| > The pipeline license **must** be FOSS, **should** not require the same license for derived | ||
| > products, and **must** be in either `LICENSE` or `LICENSE.md` in the folder of the |
There was a problem hiding this comment.
Currently, the license is an attribute of the yml file. We expect that people will refer to well-known licences, with version when appropriate. This is a change of paradigm, that allows custom licenses as well.
Do we want that?
| ### General information about the pipeline | ||
|
|
||
| - [ ] Descriptive title for the pipeline | ||
| - [ ] Authorship information with appropriate CRediT roles |
There was a problem hiding this comment.
We would need to add this to the yml description spec in the same pull request. This is surely more precise than the author/reviewer roles that I was proposing, but it would need to be turned upside down since one can have many types : to the author we add the type, and not to the author/reviewer group we add the person.
|
|
||
| - [ ] Descriptive title for the pipeline | ||
| - [ ] Authorship information with appropriate CRediT roles | ||
| - [ ] Abstract |
There was a problem hiding this comment.
Is this the markdown description that goes along iwth the pipelines, and that we display on the web page? example: https://boninabox.geobon.org/indicator?i=RLI
If yes, we would probably need another checklist for what the abstract should contain. I am weary that this .md abstract duplicates a lot of the information from the yml description file, and that it goes out of sync. The ideal would be that this page is generated by the yml file's info.
|
|
||
| ## Optional (recommended) | ||
|
|
||
| - [ ] [Mermaid][mermaid] diagram |
| - [ ] Authorship information with appropriate CRediT roles | ||
| - [ ] Abstract | ||
|
|
||
| ### Code checklist |
There was a problem hiding this comment.
I was thinking such a checklist could go in the top of the PR template (maybe link to it to avoid duplication?):
Before submitting this pull request, I have:
- Formatted my code: with appropriate indentation, clear variable names, clear function names, comments where needed, etc.
- Tested my code with the examples
- Tested my code in various contexts (region, species, time, etc.)
- Clearly documented the script yml files and in the pipeline metadata tab.
- Checked that the GitHub actions pass
- ...
|
|
||
| **GitHub repo:** <!-- REPO URL --> | ||
|
|
||
| **LICENSE:** <!-- LICENSE NAME HERE --> |
There was a problem hiding this comment.
To remove: This is per script/pipeline, and there could be different licenses in the same PR depending on IP constraints.
| **LICENSE:** <!-- LICENSE NAME HERE --> | ||
|
|
||
| > [!NOTE] | ||
| > The pipeline license **must** be FOSS, **should** not require the same license for derived |
There was a problem hiding this comment.
ici je mettrais seulement "Open Source", plutôt que FOSS, car c'est la terminologie utilisée dans le MoU qu'on signe ce soir.
| | | Initial check | | | | ||
| | | Review started | | | | ||
| | | Reviewer 1 invited | | | | ||
| | | Reviewer 2 invited | | | |
There was a problem hiding this comment.
Most review information and comments should be captured by the history of the PR. Maybe replace this table with a "progress of PR checklist" ?
Progress of Pull Request (to be filled by reviewers):
- Initial check by
- Open review call started
- Reviewers invited,
- Review 1 completed by
- Review 2 completed by
- Modifications received
- Modifications validated
- Merged
- Published on the web
|
@jmlord I'll go through your comments later this week, but meanwhile, I think the JOSS review process is a really good source of inspiration: openjournals/joss-reviews#1075 |
Work in progress
Closes #135