Open editorialbot opened 1 week ago
Hello humans, I'm @editorialbot, a robot that can help you with some common editorial tasks.
For a list of things I can do to help you, just type:
@editorialbot commands
For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:
@editorialbot generate pdf
Software report:
github.com/AlDanial/cloc v 1.90 T=0.04 s (1565.1 files/s, 137007.6 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Python 29 594 436 1953
Markdown 7 211 0 891
JSON 5 0 0 545
YAML 12 13 21 239
XML 3 0 0 139
TeX 1 10 0 109
TOML 1 8 0 90
DOS Batch 1 8 1 26
make 1 4 7 9
reStructuredText 1 8 15 3
-------------------------------------------------------------------------------
SUM: 61 856 480 4004
-------------------------------------------------------------------------------
Commit count by author:
102 Marie Houillon
73 Axel Loewe
27 Jochen Klar
7 Tomas Stary
4 Ziad Boutanios
Reference check summary (note 'MISSING' DOIs are suggestions that need verification):
β
OK DOIs
- 10.12688/f1000research.23224.2 is OK
- 10.1038/sdata.2016.18 is OK
- 10.15497/RDA00068 is OK
- 10.5281/zenodo.5171937 is OK
- 10.14454/3w3z-sa82 is OK
- 10.5063/schema/codemeta-2.0 is OK
- 10.48550/arXiv.2201.09015 is OK
- 10.35097/1979 is OK
- 10.1016/j.cmpb.2021.106223 is OK
- 10.35097/1846 is OK
- 10.35097/1799 is OK
π‘ SKIP DOIs
- None
β MISSING DOIs
- None
β INVALID DOIs
- None
Paper file info:
π Wordcount for paper.md
is 1183
β
The paper includes a Statement of need
section
License info:
β
License found: Apache License 2.0
(Valid open source OSI approved license)
@editorialbot add @AngryMaciek as reviewer
@AngryMaciek added to the reviewers list!
:point_right::page_facing_up: Download article proof :page_facing_up: View article proof on GitHub :page_facing_up: :point_left:
Also @AngryMaciek, please create your checklist typing: @editorialbot generate my checklist
:)
Hello @MarieHouillon, I'm writing some comments to the points in the review.
In general, FACILE-RS is a very valid effort relevant and potentially useful to all authors of open research software. Reliable catalogization and registration of research software in all these repositories and registries around is certainly an issue, and while everyone agrees that it should be "just done", the developers (including me) may get quite annoyed when facing the amount of petty tasks and clicking required to get everything to a perfect state.
FACILE-RS, if installed and configured properly, removes a substantial part of this burden from researchers.
In summary, I have 1 major comment about the documentation structure (see below). Other comments are minor and might not need be addressed, but it would be great to at least discuss these to see if FACILE-RS can be made more useful for the RSD crowd.
FACILE-RS satisfies the exact definition of "Research software" as given by JOSS only as a borderline match (technically it supports functioning of research instruments, for some very general definition of research instruments). On the other hand, given the utility of the software to all JOSS readers and authors, I'd still say it's in scope.
The coding effort behind the software matches the JOSS expectations, moreover the code was used previously for a few other research packages. Lines of code are not a very good metric for guessing the effort; the main value of this package is that the CI pipelines are tested and working, which takes quite a lot of effort. I can imagine my colleagues would cite this in papers about larger-scale software and data FAIRification; I would certainly use&cite this for any future configuration- and version-sensitive research software.
(I still have to verify this on my setup, but given the existing deployments I assume the functionality is already proven to be OK. Some comments provided in Documentation section also apply to the installation procedure.)
As the only major comment from my side, the documentation of FACILE-RS would deserve some revisions in order to really satisfy the expectations. In overview, although the individual parts are documented quite well, the "integration" view is largely missing.
Installation: The README should ideally provide the "deal" view of what users need to do in order to receive which functionality. In particular, it should clearly state what the "cost" for the user is (creating the CodeMeta files and modifying the GitLab CI?) to receive the "benefit" (these are documented well). Some extra comments:
PUSH_TOKEN
as well as PRIVATE_TOKEN
?)pip install
should point to a tagged stable version (or ideally "a major semver release"), which would allows people to prevent impact of future breaking changes. (Compare with e.g. GitHub actions versioning.)I'd whole-heartedly recommend addressing the issues with the installation documentation by creating an explicit "template repository" where all CI is set up and all external actions are disabled by default. With that, people can simply clone the template and merge it to their projects using git. Notably, such a template repository would also provide a quite sustainable configuration upgrade management workflow (users may just repeatedly merge the updates from the template and solve possible conflicts).
Community: A bit of documentation space should be spent on documenting the extension process. In particular, it is now unclear to me how complex it is to:
EDIT: On a very minor note, it might be useful to remove the fork relationship with the previous repository. In GitLab, this sometimes causes the merge requests to be misdirected to the fork source by default, causing various confusion and inconveniences.
Random extra notes:
create_
prefix is used for generating data from the CodeMeta (assumingly!), sometimes it means packing a package, and sometimes it also means uploading the package. prepare_
means either modifying metadata fields, or registering a DOI online. the run_*_pipeline
scripts are GravCMS specific without specifying that in the name (what if users want to extend this with another CMS support?). To alleviate the issue, it is better to use precise verbs for the command names (generate_
, register_
, update_
, pack_
, upload_
, pack_and_upload_
, ...). On a side thought, to prevent future name clashes with other tools, it is beneficial to give a common prefix to all command line utility names (e.g., facilers_update_release_metadata
? Or just frs_
?).
Submitting author: !--author-handle-->@MarieHouillon<!--end-author-handle-- (Marie Houillon) Repository: https://git.opencarp.org/openCARP/FACILE-RS Branch with paper.md (empty if default branch): joss Version: v2.1.0 Editor: !--editor-->@atrisovic<!--end-editor-- Reviewers: @exaexa, @RobLBaker, @AngryMaciek Archive: Pending
Status
Status badge code:
Reviewers and authors:
Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)
Reviewer instructions & questions
@exaexa & @RobLBaker, your review will be checklist based. Each of you will have a separate checklist that you should update when carrying out your review. First of all you need to run this command in a separate comment to create the checklist:
The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @atrisovic know.
β¨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest β¨
Checklists
π Checklist for @AngryMaciek
π Checklist for @exaexa