[REVIEW]: HeuDiConv — flexible DICOM conversion into structured directory layouts

[editorialbot]

Submitting author: @yarikoptic (Yaroslav Halchenko)
Repository: https://github.com/nipy/heudiconv/
Branch with paper.md (empty if default branch): paper-joss
Version: v1.1.6
Editor: @britta-wstnr
Reviewers: @marcelzwiers, @JLefortBesnard
Archive: 10.5281/zenodo.11497270

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/0f2a27d2e6cc5fc58892c34b73b82151"><img src="https://joss.theoj.org/papers/0f2a27d2e6cc5fc58892c34b73b82151/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/0f2a27d2e6cc5fc58892c34b73b82151/status.svg)](https://joss.theoj.org/papers/0f2a27d2e6cc5fc58892c34b73b82151)

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

@marcelzwiers & @JLefortBesnard, 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:

@editorialbot generate my checklist

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @britta-wstnr 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 @marcelzwiers

📝 Checklist for @JLefortBesnard

[editorialbot]

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

[editorialbot]

Software report:

github.com/AlDanial/cloc v 1.88  T=0.03 s (544.8 files/s, 32416.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                           7             67             56            333
Markdown                         3             36              0            223
YAML                             1              0              0            195
TeX                              1             11              4            117
SQL                              1              0              1             12
make                             1              2              0              8
JSON                             3              0              0              3
Bourne Shell                     1              1              0              2
-------------------------------------------------------------------------------
SUM:                            18            117             61            893
-------------------------------------------------------------------------------


gitinspector failed to run statistical information for the repository

[editorialbot]

Wordcount for paper.md is 2248

[editorialbot]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1038/sdata.2016.44 is OK
- 10.21105/joss.03262 is OK
- 10.1016/j.jneumeth.2016.03.001 is OK
- 10.1038/s41597-021-01042-2 is OK
- 10.18112/OPENNEURO.DS003382.V1.0.0 is OK
- 10.3389/fninf.2021.678403 is OK
- 10.1038/sdata.2014.3 is OK
- 10.5281/ZENODO.7319790 is OK
- 10.3389/fninf.2011.00013 is OK
- 10.5281/ZENODO.1058997 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[editorialbot]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[britta-wstnr]

Hello again! 👋

@marcelzwiers @JLefortBesnard
FYI @yarikoptic

This is the review thread for the paper. All of our higher-level communications will happen here from now on, review comments and discussion can happen in the repository of the project (details below).

📓 Please read the "Reviewer instructions & questions" in the comment from our editorialbot (above).
✅ All reviewers get their own checklist with the JOSS requirements - you generate them as per the details in the editorialbot comment. As you go over the submission, please check any items that you feel have been satisfied.
💻 The JOSS review is different from most other journals: The reviewers are encouraged to submit issues and pull requests on the software repository. When doing so, please mention #5839 so that a link is created to this thread. That will also help me to keep track!
❓ Please also feel free to comment and ask questions on this thread.
🎯 We aim for the review process to be completed within about 4-6 weeks but please make a start well ahead of this as JOSS reviews are by their nature iterative and any early feedback you may be able to provide to the author will be very helpful in meeting this schedule.

[marcelzwiers]

Review checklist for @marcelzwiers

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/nipy/heudiconv/?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@yarikoptic) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[britta-wstnr]

Hi @JLefortBesnard,

let me know if you have any questions or anything is unclear regarding the next steps!
It would be great if you could just generate your checklist so I can see that everything is in order 😄

[britta-wstnr]

Ping @JLefortBesnard again, would you mind generating your checklist to see everything is in order? Thanks a lot! 🙏

[marcelzwiers]

Heudiconv is probably the best known and most used software tool for researchers who would like to do open science and organize their data according to the BIDS standard. The heudiconv paper is well written but brief and rather incomplete without the online read-the-docs documentation. I felt that after reading the paper I didn't get an idea about the architecture of Heudiconv, i.e. how the heuristics are used, what the main workflow is (the paper mentions "discovery, manual tuning, conversion" steps without properly explaining what they are. In the tutorials it is mentioned that you first may have to generate a dicominfo.tsv file that can then be used to construct a heuristic file, but as a reader you have to connect all the dots yourself. To get a better understanding of the heuristics file, I looked at a few (third party) tutorials and opened the studyforrest_phase2.py file. Then I understood a bit more, but many things remained unexplained or untouched. I then opened the reproin.py file, but found a staggering 926 lines of code to reverse engineer... I understand that this is advanced usage that is beyond the scope of the paper, but I would expect a basic explanation of the workflow of getting a dicominfo.tsv file, an explanation that you, as a user, have to write python code to make conversion keys from seqinfo data that is provided by heudiconv (a little bit of heuristics code and a snippet of seqinfo would have been helpful).

About the paper, I have a few more comments:

Figure 1 contains details about the data acquisition (k-space!) that have nothing to do with heudiconv. Also, the figure contains several post-heudiconv use cases, which are very general and uninformative about heudiconv. In the figure, heudiconv itself is just one black box! Altogether, I suggest to remove the figure or replace it with a flow-chart of heudiconv itself (the inside of the black box), or of it's workflow (or both).

Open general checks:

• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.

Figure 2 from the paper contains original data (arguably) but I cannot access the data nor reproduce the figure. I looked into etelemetry but the data is stored on a private server. I also looked at the pypi data, but in order to access that I believe I would need a (payed) Google Cloud BigQuery account. I am fine with accepting these checks if the editor does not consider download metrics as original data (although it would be nice if the authors explain a bit more on how the data was generated)

Open functionality checks:
-Functionality: Have the functional claims of the software been confirmed?

The paper makes many functional claims, e.g. that it can handle complex data structures, data acquisitions schemes, and much more. I could not verify all claims but did try to convert a (relatively simple) standard dataset using the convertall heuristics and --bids flag. That worked (after some struggles) but the output was not in BIDS format. Yet, I do suspect that this wouldn't have been the case if I had written a custom heuristics file. And given the evidence of researchers in the field having used heudiconv to convert more complex datasets to BIDS I'm happy to check this box if the editor is ok with that.

Open documentation checks:

• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

I have already touched upon these checks in my general comment. Several examples (if third party tutorials count as examples) can be found on the read-the-docs website, but not in the paper. I would have liked to see a simple example in the paper (not in detail, but to get an idea what of what is involved and what the user would need to do). The same is true for the core functionality, it is described at the website but the paper basically only states "that decision making is implemented in HeuDiConv heuristics" and that heudiconv can operate in BIDS mode with a --bids flag.

Open software paper checks:

• State of the field: Do the authors describe how this software compares to other commonly-used packages?

Importantly, this is missing entirely. The limitations of heudiconv are not discussed (I think it should at least be mentioned that you have to be able to program Python, get to know the heudiconv API + that you need to have some understanding of pulse sequence parameters), neither is there discussion how heudiconv's advantages and disadvantages compare to those of other tools in the field.

[britta-wstnr]

Hi @marcelzwiers -
thank you very much for your detailed review! 👍
One comment for you and @yarikoptic: your feedback towards the gaps in the paper touches upon a specialty of JOSS papers. They are meant to be very brief (250 to 1000 words only! https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain) and should not contain documentation of API* etc (https://joss.readthedocs.io/en/latest/review_criteria.html).
However, this should be part of the documentation, so if you @marcelzwiers had problems understanding the architecture/API of the toolbox based on the docs, then this should be changed.

*one reason for this is that API documentation in papers often becomes obsolete after a few years, while the docs are a "living" thing that changes alongside the code.

[yarikoptic]

@marcelzwiers thank you for the review! And thank you @britta-wstnr for a valuable comment: we will take it into account while responding to the review(s), which we hope to do within a week.

[JLefortBesnard]

Review checklist for @JLefortBesnard

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the https://github.com/nipy/heudiconv/?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@yarikoptic) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines
• Data sharing: If the paper contains original data, data are accessible to the reviewers. If the paper contains no original data, please check this item.
• Reproducibility: If the paper contains original results, results are entirely reproducible by reviewers. If the paper contains no original results, please check this item.
• Human and animal research: If the paper contains original data research on humans subjects or animals, does it comply with JOSS's human participants research policy and/or animal research policy? If the paper contains no such data, please check this item.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of need' that clearly states what problems the software is designed to solve, who the target audience is, and its relation to other work?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[JLefortBesnard]

Hi @JLefortBesnard,

let me know if you have any questions or anything is unclear regarding the next steps! It would be great if you could just generate your checklist so I can see that everything is in order 😄

Hello, I am really sorry for the delay, I didn't realize the reviewing had started, I'll get started and provide my feedback quickly. Thank you @britta-wstnr for the reminder email 🙂

[JLefortBesnard]

Hello,
Setting up the process of converting DICOM to BIDS is not an easy task, and yet, very much necessary for reproducibility. HeuDiConv, as a software tool to provide advanced and adaptable BIDS dataset creation, fully meets this request and the range of available pre-defined heuristics simplifies the usage.

Many great tutorials are available, I followed two of them and found them quite clear. In fact, the tutorials' quality accentuates the disparity with the "read-the-docs" even more. Though it is sufficiently clear to individuals who have prior experience in converting Dicom to Bids using Python (that is why I did check the 'functionality documentation' box), I feel that the documentation is perhaps not designed in the most user-friendly manner for newcomers, and thus does not provide enough guidance to make the usage more intuitive. Striving in this direction might be beneficial in promoting the use of this tool.

I find the paper well-crafted and providing enough information for a solid understanding of the software. I appreciate Figure 1, which effectively illustrates the software's functionality. However, I have reservations about Figure 2, which, in my opinion, may not be relevant to the user since the information can be adequately summarized in the text. Instead, including a second figure that depicts the inner workings of the software, as the first reviewer suggested, would be more engaging.

I also agree with the first reviewer about the missing limitations of HeuDiConv and the missing comparison with other similar tools (or ways) to convert DICOM into Bids (that is why I did not check the 'state of the field' box).

I did not test all functional claims made in the paper ("complex organization scenario") thus cannot confirm them.

Overall, I think this paper belongs in JOSS. This tool is poised to make a significant impact on the neuroimaging community, and I will use it too.

[yarikoptic]

Thank you @JLefortBesnard for the review! Would you mind sharing which particular 2 tutorials you found "quite clear"?

[JLefortBesnard]

Thank you @JLefortBesnard for the review! Would you mind sharing which particular 2 tutorials you found "quite clear"?

Sure, I enjoyed the tutorials from James Kent and the one from Stanford

[britta-wstnr]

Hi @yarikoptic - just checking in if everything is going alright here? 🙂 Or if there is anything you'd need help with from the editorial side?

[yarikoptic]

Hi @britta-wstnr , thanks for checking in! Sorry for the delay - were busy with SfN booth fun and now all involved are fighting the COVID after that fun ;) I hope we would get back to this by early next week.

[britta-wstnr]

No worries at all @yarikoptic - I just wanted to make sure there are no open questions. Get well soon! 🍵

[britta-wstnr]

@yarikoptic I hope you are feeling better. Just checking in here - also to say that I will be out of office for winter break soon, so I might be slow to respond for a while. ❄️ ⛄

[Kevin-Mattheus-Moerman]

@editorialbot accept

[editorialbot]

Doing it live! Attempting automated processing of paper acceptance...

[editorialbot]

Ensure proper citation by uploading a plain text CITATION.cff file to the default branch of your repository.

If using GitHub, a Cite this repository menu will appear in the About section, containing both APA and BibTeX formats. When exported to Zotero using a browser plugin, Zotero will automatically create an entry using the information contained in the .cff file.

You can copy the contents for your CITATION.cff file here:

CITATION.cff

cff-version: "1.2.0"
authors:
- family-names: Halchenko
  given-names: Yaroslav O.
  orcid: "https://orcid.org/0000-0003-3456-2493"
- family-names: Goncalves
  given-names: Mathias
  orcid: "https://orcid.org/0000-0002-7252-7771"
- family-names: Ghosh
  given-names: Satrajit
  orcid: "https://orcid.org/0000-0002-5312-6729"
- family-names: Velasco
  given-names: Pablo
  orcid: "https://orcid.org/0000-0002-5749-6049"
- family-names: Oleggio Castello
  given-names: Matteo Visconti
  name-particle: di
  orcid: "https://orcid.org/0000-0001-7931-5272"
- family-names: Salo
  given-names: Taylor
  orcid: "https://orcid.org/0000-0001-9813-3167"
- family-names: II
  given-names: John T. Wodder
- family-names: Hanke
  given-names: Michael
  orcid: "https://orcid.org/0000-0001-6398-6370"
- family-names: Sadil
  given-names: Patrick
  orcid: "https://orcid.org/0000-0003-4141-1343"
- family-names: Gorgolewski
  given-names: Krzysztof Jacek
  orcid: "https://orcid.org/0000-0003-3321-7583"
- family-names: Ioanas
  given-names: Horea-Ioan
  orcid: "https://orcid.org/0000-0001-7037-2449"
- family-names: Rorden
  given-names: Chris
  orcid: "https://orcid.org/0000-0002-7554-6142"
- family-names: Hendrickson
  given-names: Timothy J.
  orcid: "https://orcid.org/0000-0001-6862-6526"
- family-names: Dayan
  given-names: Michael
  orcid: "https://orcid.org/0000-0002-2666-0969"
- family-names: Houlihan
  given-names: Sean Dae
  orcid: "https://orcid.org/0000-0001-5003-9278"
- family-names: Kent
  given-names: James
  orcid: "https://orcid.org/0000-0002-4892-2659"
- family-names: Strauss
  given-names: Ted
  orcid: "https://orcid.org/0000-0002-1927-666X"
- family-names: Lee
  given-names: John
  orcid: "https://orcid.org/0000-0001-5884-4247"
- family-names: To
  given-names: Isaac
  orcid: "https://orcid.org/0000-0002-4740-0824"
- family-names: Markiewicz
  given-names: Christopher J.
  orcid: "https://orcid.org/0000-0002-6533-164X"
- family-names: Lukas
  given-names: Darren
  orcid: "https://orcid.org/0009-0003-6941-0833"
- family-names: Butler
  given-names: Ellyn R.
  orcid: "https://orcid.org/0000-0001-6316-6444"
- family-names: Thompson
  given-names: Todd
- family-names: Termenon
  given-names: Maite
  orcid: "https://orcid.org/0000-0001-8102-5135"
- family-names: Smith
  given-names: David V.
  orcid: "https://orcid.org/0000-0001-5754-9633"
- family-names: Macdonald
  given-names: Austin
  orcid: "https://orcid.org/0000-0002-8124-807X"
- family-names: Kennedy
  given-names: David N.
  orcid: "https://orcid.org/0000-0002-9377-0797"
doi: 10.5281/zenodo.11497270
message: If you use this software, please cite our article in the
  Journal of Open Source Software.
preferred-citation:
  authors:
  - family-names: Halchenko
    given-names: Yaroslav O.
    orcid: "https://orcid.org/0000-0003-3456-2493"
  - family-names: Goncalves
    given-names: Mathias
    orcid: "https://orcid.org/0000-0002-7252-7771"
  - family-names: Ghosh
    given-names: Satrajit
    orcid: "https://orcid.org/0000-0002-5312-6729"
  - family-names: Velasco
    given-names: Pablo
    orcid: "https://orcid.org/0000-0002-5749-6049"
  - family-names: Oleggio Castello
    given-names: Matteo Visconti
    name-particle: di
    orcid: "https://orcid.org/0000-0001-7931-5272"
  - family-names: Salo
    given-names: Taylor
    orcid: "https://orcid.org/0000-0001-9813-3167"
  - family-names: II
    given-names: John T. Wodder
  - family-names: Hanke
    given-names: Michael
    orcid: "https://orcid.org/0000-0001-6398-6370"
  - family-names: Sadil
    given-names: Patrick
    orcid: "https://orcid.org/0000-0003-4141-1343"
  - family-names: Gorgolewski
    given-names: Krzysztof Jacek
    orcid: "https://orcid.org/0000-0003-3321-7583"
  - family-names: Ioanas
    given-names: Horea-Ioan
    orcid: "https://orcid.org/0000-0001-7037-2449"
  - family-names: Rorden
    given-names: Chris
    orcid: "https://orcid.org/0000-0002-7554-6142"
  - family-names: Hendrickson
    given-names: Timothy J.
    orcid: "https://orcid.org/0000-0001-6862-6526"
  - family-names: Dayan
    given-names: Michael
    orcid: "https://orcid.org/0000-0002-2666-0969"
  - family-names: Houlihan
    given-names: Sean Dae
    orcid: "https://orcid.org/0000-0001-5003-9278"
  - family-names: Kent
    given-names: James
    orcid: "https://orcid.org/0000-0002-4892-2659"
  - family-names: Strauss
    given-names: Ted
    orcid: "https://orcid.org/0000-0002-1927-666X"
  - family-names: Lee
    given-names: John
    orcid: "https://orcid.org/0000-0001-5884-4247"
  - family-names: To
    given-names: Isaac
    orcid: "https://orcid.org/0000-0002-4740-0824"
  - family-names: Markiewicz
    given-names: Christopher J.
    orcid: "https://orcid.org/0000-0002-6533-164X"
  - family-names: Lukas
    given-names: Darren
    orcid: "https://orcid.org/0009-0003-6941-0833"
  - family-names: Butler
    given-names: Ellyn R.
    orcid: "https://orcid.org/0000-0001-6316-6444"
  - family-names: Thompson
    given-names: Todd
  - family-names: Termenon
    given-names: Maite
    orcid: "https://orcid.org/0000-0001-8102-5135"
  - family-names: Smith
    given-names: David V.
    orcid: "https://orcid.org/0000-0001-5754-9633"
  - family-names: Macdonald
    given-names: Austin
    orcid: "https://orcid.org/0000-0002-8124-807X"
  - family-names: Kennedy
    given-names: David N.
    orcid: "https://orcid.org/0000-0002-9377-0797"
  date-published: 2024-07-03
  doi: 10.21105/joss.05839
  issn: 2475-9066
  issue: 99
  journal: Journal of Open Source Software
  publisher:
    name: Open Journals
  start: 5839
  title: HeuDiConv --- flexible DICOM conversion into structured
    directory layouts
  type: article
  url: "https://joss.theoj.org/papers/10.21105/joss.05839"
  volume: 9
title: HeuDiConv --- flexible DICOM conversion into structured directory
  layouts

If the repository is not hosted on GitHub, a .cff file can still be uploaded to set your preferred citation. Users will be able to manually copy and paste the citation.

Find more information on .cff files here and here.

[editorialbot]

🐘🐘🐘 👉 Toot for this paper 👈 🐘🐘🐘

[editorialbot]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.05839 joss-papers#5572
1. Wait five minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.05839
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

[mvdoc]

I noticed that the automatically generated crossref file has some errors in how first names/last names were parsed. I'm not sure if it matters but I just wanted to point it out.
(My last name always creates issues with automatic parsers, but I also noticed there were errors with at least another name):

https://github.com/openjournals/joss-papers/blob/master/joss.05839/10.21105.joss.05839.crossref.xml

          <person_name sequence="additional"
                       contributor_role="author">
            <given_name>Matteo Visconti</given_name>
            <surname>di Oleggio Castello</surname>
            <ORCID>https://orcid.org/0000-0001-7931-5272</ORCID>
          </person_name>
...
          <person_name sequence="additional"
                       contributor_role="author">
            <given_name>John T. Wodder</given_name>
            <surname>II</surname>
          </person_name>

[danielskatz]

If the names are described in the .md file as explained in https://joss.readthedocs.io/en/latest/paper.html#names, this shouldn't happen. If they aren't, they could be fixed, and the paper could be reaccepted to fix this.

[mvdoc]

Thanks @danielskatz. We have fixed the .md file in nipy/heudiconv#772.

[danielskatz]

the track chair, @Kevin-Mattheus-Moerman, should next do a reaccept to update the metadata deposited with Crossref.

[Kevin-Mattheus-Moerman]

@editorialbot reaccept

[editorialbot]

Rebuilding paper!

[editorialbot]

⚠️ Couldn't update published paper. An error happened. The generated XML metadata file is invalid.

Element surname: [facet 'minLength'] The value has a length of '0'; this underruns the allowed minimum length of '1'.
Element surname: [facet 'pattern'] The value '' is not accepted by the pattern '[^\d\?]*[^\?\s]+[^\d]*'.

[Kevin-Mattheus-Moerman]

@openjournals/dev @danielskatz do you know how to address this error?

[danielskatz]

@Kevin-Mattheus-Moerman - I see two problems in the metadata, thought neither matches the error messages
Lines 39 and 103 (empty orcid entries) should be removed.
The affiliations also aren't quoted, which might be ok when there is only one but typically fails when there are multiple.
I see that these are not new issues, so I'm unsure why they would be problems now, when they were not before, unless the logic that JOSS uses for multiple name parts is more strict that for single name fields.

perhaps @xuanxu will have thoughts as well?

[Kevin-Mattheus-Moerman]

Thanks @danielskatz. @yarikoptic Perhaps you can work on some of the points Dan mentioned so we can test that while we wait on @xuanxu to shed more light on this.

[xuanxu]

There is a typo in one of the metadata keys (surmame for surname), this PR should fix the error.

[yarikoptic]

big thanks @xuaxu! merged

@editorialbot generate pdf

[Kevin-Mattheus-Moerman]

@editorialbot reaccept

[editorialbot]

Rebuilding paper!

[editorialbot]

🌈 Paper updated!

New PDF and metadata files 👉 openjournals/joss-papers#5586

[Kevin-Mattheus-Moerman]

@yarikoptic can you confirm all looks good now? Thanks!

[yarikoptic]

Looks great to me, Seems to look good for @mvdoc 's name:

https://github.com/openjournals/joss-papers/blob/master/joss.05839/10.21105.joss.05839.crossref.xml#L67

          <person_name sequence="additional"
                       contributor_role="author">
            <given_name>Matteo</given_name>
            <surname>Visconti di Oleggio Castello</surname>
            <ORCID>https://orcid.org/0000-0001-7931-5272</ORCID>
          </person_name>

Huge Thanks EVERYONE who was with us on this journey!

[britta-wstnr]

Congratulations @yarikoptic and team!

[Kevin-Mattheus-Moerman]

Congratulations @yarikoptic

Thanks for editing @britta-wstnr

And a special thank you to the reviewers: @marcelzwiers, @JLefortBesnard !!

[editorialbot]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.05839/status.svg)](https://doi.org/10.21105/joss.05839)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.05839">
  <img src="https://joss.theoj.org/papers/10.21105/joss.05839/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.05839/status.svg
   :target: https://doi.org/10.21105/joss.05839

This is how it will look in your documentation:

We need your help!

The Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://reviewers.joss.theoj.org/join
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss