Joss-reviews: [REVIEW]: `tqdm`: A Fast, Extensible Progress Meter for Python and CLI

[whedon]

Submitting author: @casperdcl (da Costa-Luis, Casper O.)
Repository: https://github.com/tqdm/tqdm
Version: v4.32.1
Editor: @cMadan
Reviewer: @GregaVrbancic, @Benjamin-Lee
Archive: 10.5281/zenodo.2800317

Status

Status badge code:

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

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) 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

@GregaVrbancic & @Benjamin-Lee, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.theoj.org/about#reviewer_guidelines. Any questions/concerns please let @cMadan know.

✨ Please try and complete your review in the next two weeks ✨

Review checklist for @GregaVrbancic

Conflict of interest

• [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

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

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Version: v4.32.1
• [x] Authorship: Has the submitting author (@casperdcl) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] 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

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] 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

• [x] Authors: Does the paper.md file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

Review checklist for @Benjamin-Lee

Conflict of interest

• [x] As the reviewer I confirm that I have read the JOSS conflict of interest policy and that there are no conflicts of interest for me to review this work.

Code of Conduct

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

General checks

• [x] Repository: Is the source code for this software available at the repository url?
• [x] License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• [x] Version: v4.32.1
• [x] Authorship: Has the submitting author (@casperdcl) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

Functionality

• [x] Installation: Does installation proceed as outlined in the documentation?
• [x] Functionality: Have the functional claims of the software been confirmed?
• [x] 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

• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• [x] Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• [x] Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• [x] Automated tests: Are there automated tests or manual steps described so that the function of the software can be verified?
• [x] 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

• [x] Authors: Does the paper.md file include a list of authors with their affiliations?
• [x] A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• [x] References: Do all archival references that should have a DOI list one (e.g., papers, datasets, software)?

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @GregaVrbancic, it looks like you're currently assigned as the reviewer for this paper :tada:.

:star: Important :star:

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

1. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

For a list of things I can do to help you, just type:

@whedon commands

[whedon]

Attempting PDF compilation. Reticulating splines etc...

[whedon]

PDF failed to compile for issue #1277 with the following error:

/app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/lib/whedon.rb:83:in check_fields': Paper YAML header is missing expected fields: affiliations, bibliography (RuntimeError) from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/lib/whedon.rb:69:ininitialize'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/lib/whedon/processor.rb:32:in new' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/lib/whedon/processor.rb:32:inset_paper'
from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/bin/whedon:55:in prepare' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/command.rb:27:inrun'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in invoke_command' from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor.rb:387:indispatch'
from /app/vendor/bundle/ruby/2.4.0/gems/thor-0.20.3/lib/thor/base.rb:466:in start' from /app/vendor/bundle/ruby/2.4.0/bundler/gems/whedon-01ece1d1d135/bin/whedon:116:in from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in load' from /app/vendor/bundle/ruby/2.4.0/bin/whedon:23:in

'

[casperdcl]

@cMadan @GregaVrbancic, @Benjamin-Lee please use the tqdm:devel branch for review, I can commit any suggested changes there and make a new release before (hopeful) acceptance

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[cMadan]

@GregaVrbancic @Benjamin-Lee, how is the review coming?

[GregaVrbancic]

@cMadan I'm planning to complete the review later today. Sorry for a bit of delay, due to the work stuff.

[GregaVrbancic]

So, here is my review of this submission. In general, the package seems really nice, but in order to publish this paper I have some minor suggestions or remarks:

1. Stephen Larroque appears to be a significant contributor. Have you considered adding him in the authors' list?
2. I have read the discussion about the scope of the paper and the target audience in #1258. My opinion is that the target audience could be more explicitly defined, but if @cMadan is fine with the current state, I will not insist on making any changes.
3. In the references list, the reference with id tqdm-ar has release year and publisher defined differently as here.
4. The iterable-based usage example featuring trange is not working out of the box. It would be nice if the example would also have the import statement for trange defined.
5. Some guidelines on reporting issues or seeking support could be added.

@casperdcl please take a look at the listed remarks.

@cMadan I have a question regarding the whedon check references command. Is it possible to run it against the devel branch? Maybe in the same manner as whedon generate pdf from branch devel?

[casperdcl]

thanks @GregaVrbancic; will respond in more detail later.

1. Stephen (@lrq3000), I know you haven't contributed in years but would be great to have you back on the team
2. Any suggestions?
3. Will check
4. Will update
5. Will add links to relevant documentation

[Benjamin-Lee]

Initial thoughts on the paper:

1. If @arfon and @cMadan are happy with tqdm being in JOSS's scope, then I have no issues. To my mind, the more peer reviewed published software, the better.
2. The structure of the paper requires work. Specifically, I would move the popularity section to the introduction and convert it to prose from bullets and eliminate the "see also" and "references in blogs" sections. JOSS papers generally use a single "summary" section. I would suggest attempting to do the same if at all possible. If you think you can't make it work in one section, this paper is a very good example of a well structured but complex JOSS paper. In general, I would suggest collapsing the bullets to paragraphs (with the exception of the first set in the summary, which I think works well)
3. I don't think there's any need for the logo in the paper.
4. The third sentence, explaining the meaning of the tqdm, is unnecessary.
5. The bibliography seems to have a lot of redundant information. To start, I would suggest collapsing the GitHub references down to one.
6. In the license section, I would remove the wording about citing tqdm on Zenodo since it'll be cited in JOSS!

Overall, tqdm is a great tool with wide applicability to both research and general software development. The repo is quite well organized and the code well documented. If I were to choose an area for improvement in the repo (though there isn't really much), I would suggest more developer documentation describing the structure of the tqdm/tqdm directory, since some of the files such as _main.py __main__.py are similarly named.

[casperdcl]

Full Response

Firstly, thank you @GregaVrbancic and @Benjamin-Lee (and @cMadan) for your time and reviews.

Review 1 (@GregaVrbancic)

1. > Stephen Larroque appears to be a significant contributor. Have you considered adding him in the authors' list?
2. I hope my comment (https://github.com/openjournals/joss-reviews/issues/1277#issuecomment-469222023) addresses this.
3. > I have read the discussion about the scope of the paper and the target audience in #1258. My opinion is that the target audience could be more explicitly defined, but if @cMadan is fine with the current state, I will not insist on making any changes.
4. Any suggestions as to how the audience could be more explicitly defined? On , the intended audience is listed (based on https://pypi.org/pypi?%3Aaction=list_classifiers) - I can mirror this in the paper if you'd like.
5. > In my opinion, a brief description of the target audience (based on https://pypi.org/pypi?%3Aaction=list_classifiers) would be useful and would improve the overall quality of the paper. Keep in mind that not all of the JOSS audience will go through the classifiers listed on PyPI package site.
6. Thanks, I have appended a description to the Introduction.
7. > In the references list, the reference with id tqdm-ar has release year and publisher defined differently as here.
8. Thanks for pointing this out. I think this link must be wrong: https://books.google.co.uk/books/about/Early_Southern_Arabian_Languages_and_Cla.html?id=42tjAAAAMAAJ. I have updated the reference in the paper.
9. > The iterable-based usage example featuring trange is not working out of the box. It would be nice if the example would also have the import statement for trange defined.
10. I assume this refers to https://github.com/tqdm/tqdm/#iterable-based and related to https://github.com/tqdm/tqdm/pull/495. I have updated the example, making it more stand-alone like or .
11. > Some guidelines on reporting issues or seeking support could be added.
12. Does this comment refer to the repository or the paper itself?
    If it's the repository, there's https://github.com/tqdm/tqdm/#contributions or https://tqdm.github.io/contributing/.
13. > Yes, I was refe[r]ring to the repository. Look at the review checklist, sect[i]on Documentation, subsection Community guidelines. You have ad[d]ressed the the 1) nicely in the documentation, but I was aiming more toward the points 2) and 3), or have I missed something?
14. There's https://github.com/tqdm/tqdm#faq-and-known-issues which mentions .
    I have now updated the latter to point to all issues (including closed ones and PRs), and added both links to the website (https://tqdm.github.io/) now so they're harder to miss.
    N.B. anyone attempting to file a new issue/PR is presented with a message:
    > - [ ] I have visited the [source website], and in particular
    > read the [known issues]
    > - [ ] I have searched through the [issue tracker] for duplicates
    > - [ ] I have mentioned version numbers, operating system and
    > environment, where applicable:
    > python > import tqdm, sys > print(tqdm.__version__, sys.version, sys.platform) >
    > - [ ] If applicable, I have mentioned the relevant/related issue(s)

General Comments

• The JOSS review checkboxes are a little confusing to me. I think the Documentation section refers to framework of the repository itself, and nothing to do with paper content. As such, I think all points are more than addressed:
  
  
  
  • A statement of need: https://github.com/tqdm/tqdm or https://tqdm.github.io
  
  
  • Community guidelines: https://github.com/tqdm/tqdm/#contributions or https://tqdm.github.io/contributing/ as mentioned in (5) above
  
  
• However, I intend tqdm as a gold-standard reference for repository management/framework, and thus would be very willing to make any suggested changes to make things clearer.

Review 2 (@Benjamin-Lee)

1. > If @arfon and @cMadan are happy with tqdm being in JOSS's scope, then I have no issues. To my mind, the more peer reviewed published software, the better.
2. If there are other journal(s) you can recommend, I'd be happy to submit there instead if you feel it's more appropriate. I think tqdm is one of the world's most used Python packages ( and ; usually on the first page of https://libraries.io/search?order=desc&platforms=PyPI&sort=rank) because its scope is pretty large.
3. > The structure of the paper requires work. Specifically, I would move the popularity section to the introduction and convert it to prose from bullets and eliminate the "see also" and "references in blogs" sections. JOSS papers generally use a single "summary" section. I would suggest attempting to do the same if at all possible. If you think you can't make it work in one section, this paper is a very good example of a well structured but complex JOSS paper. In general, I would suggest collapsing the bullets to paragraphs (with the exception of the first set in the summary, which I think works well)
4. I've endeavoured to reorder, make prosaic, and eliminate as requested.
5. > I don't think there's any need for the logo in the paper.
6. Removed.
7. > The third sentence, explaining the meaning of the tqdm, is unnecessary.
8. I feel etymological explanation/justification of an otherwise seemingly random combination of letters is important. The other reviewer was kind enough to point out a mistake in the reference here. I'm happy to leave this to the editor to decide.
9. > The bibliography seems to have a lot of redundant information. To start, I would suggest collapsing the GitHub references down to one.
10. I tried to keep the reference count down. Unfortunately I can't see where I can merge two references as they are all unique citations for specific claims.
11. > In the license section, I would remove the wording about citing tqdm on Zenodo since it'll be cited in JOSS!
12. Reworded.

General Comments

Overall, tqdm is a great tool with wide applicability to both research and general software development. The repo is quite well organized and the code well documented. If I were to choose an area for improvement in the repo (though there isn't really much), I would suggest more developer documentation describing the structure of the tqdm/tqdm directory, since some of the files such as _main.py __main__.py are similarly named.

Thank you. I intend tqdm as a gold-standard reference for repository management/framework, and thus would be very willing to make any suggested changes to make things clearer.
I'm sure you've seen
https://github.com/tqdm/tqdm/#contributions or
https://tqdm.github.io/contributing/.

Regarding the layout,
https://github.com/tqdm/tqdm/pull/198#issuecomment-394184136 is a heavily
revised comment in a milestone v5 release that's past due by about 2
years due to a personal lack of time!
I will incorporate that comment (likely heavily revised) into the developer
documentation when that issue is eventually addressed.

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[casperdcl]

Looks ready to me for a re-check now. Will merge into master if it's ok.

[GregaVrbancic]

@casperdcl please consider the following proposed improvements.

1. > I have read the discussion about the scope of the paper and the target audience in #1258. My opinion is that the target audience could be more explicitly defined, but if @cMadan is fine with the current state, I will not insist on making any changes.

• Any suggestions as to how the audience could be more explicitly defined? On , the intended audience is listed (based on https://pypi.org/pypi?%3Aaction=list_classifiers) - I can mirror this in the paper if you'd like.

In my opinion, a brief description of the target audience (based on https://pypi.org/pypi?%3Aaction=list_classifiers) would be useful and would improve the overall quality of the paper. Keep in mind that not all of the JOSS audience will go through the classifiers listed on PyPI package site.

1. > Some guidelines on reporting issues or seeking support could be added.

• Does this comment refer to the repository or the paper itself?
  If it's the repository, there's https://github.com/tqdm/tqdm/#contributions or https://tqdm.github.io/contributing/.

Yes, I was refering to the repository. Look at the review checklist, secton Documentation, subsection Community guidelines. You have adressed the the 1) nicely in the documentation, but I was aiming more toward the points 2) and 3), or have I missed something?

My other remarks you've addressed properly in my opinion.

[casperdcl]

Thanks @GregaVrbancic. I've update my response above (but also explicit the changes below):

1. > In my opinion, a brief description of the target audience (based on https://pypi.org/pypi?%3Aaction=list_classifiers) would be useful and would improve the overall quality of the paper. Keep in mind that not all of the JOSS audience will go through the classifiers listed on PyPI package site.
2. Thanks, I have appended a description to the Introduction.
3. > Yes, I was refe[r]ring to the repository. Look at the review checklist, sect[i]on Documentation, subsection Community guidelines. You have ad[d]ressed the the 1) nicely in the documentation, but I was aiming more toward the points 2) and 3), or have I missed something?
4. There's https://github.com/tqdm/tqdm#faq-and-known-issues which mentions .
   I have now updated the latter to point to all issues (including closed ones and PRs), and added both links to the website (https://tqdm.github.io/) now so they're harder to miss.
   N.B. anyone attempting to file a new issue/PR is presented with a message:
   > - [ ] I have visited the [source website], and in particular
   > read the [known issues]
   > - [ ] I have searched through the [issue tracker] for duplicates
   > - [ ] I have mentioned version numbers, operating system and
   > environment, where applicable:
   > python > import tqdm, sys > print(tqdm.__version__, sys.version, sys.platform) >
   > - [ ] If applicable, I have mentioned the relevant/related issue(s)

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[cMadan]

@casperdcl @GregaVrbancic @Benjamin-Lee, just to follow-up re: scope of work and JOSS. I appreciate both reviewers commenting on this--I do agree that the project is on the edge of JOSS' scope (and had brought this up in the pre-review). However, we have published tools that are similarly tools for researchers/development (rather than researcher end-users) and tdqm has clearly demonstrated it's utility as a development tool, so we are considering it within-scope here. I think the statement of need provided in the paper is sufficient, but suggestions to improve it are, of course, welcome.

[GregaVrbancic]

@cMadan thank you for the follow-up. I think that @casperdcl has addressed all my remarks, so from my standpoint, the paper could proceed to publish.

[cMadan]

@GregaVrbancic, thank you for the thorough review!

@Benjamin-Lee, please look over the repo again when you have a chance and let me know what you think.

[cMadan]

@Benjamin-Lee, could you take a quick look to see if your last comments were suitably addressed? Thanks!

[Benjamin-Lee]

One last tiny change and then I think it's good to go:

within a Command-line interface

Should this be CLI (since you defined the acronym in the previous section) or within a command-line interface with a lowercase c>

Either way, congrats @casperdcl!

[casperdcl]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[casperdcl]

Thanks @Benjamin-Lee @GregaVrbancic.

@cMadan let me know what the next steps are - ideally I'd like to merge into master before official publication.

[casperdcl]

erm ping @cMadan

[labarba]

@casperdcl, FYI, I have followed up with the editor, and he is on travel but will update us soon.

[cMadan]

@whedon generate pdf from branch devel

[whedon]

Attempting PDF compilation from custom branch devel. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[cMadan]

@casperdcl, everything looks good and I'm almost ready to accept. Let me know after you merge into master and have the new GitHub release and new Zenodo DOI minted, then I'll finalise things here.

[casperdcl]

@whedon generate pdf from branch master

[whedon]

Attempting PDF compilation from custom branch master. Reticulating splines etc...

[whedon]

:point_right: Check article proof :page_facing_up: :point_left:

[casperdcl]

@cMadan all done: merged, tagged (v4.32.0) and released on all channels (GitHub/Zenodo/PyPI/Conda/DockerHub/Snapcraft). https://github.com/tqdm/tqdm#tqdm for all relevant badges/links.

[casperdcl]

note that this is more recent than the version mentioned in the original (https://github.com/openjournals/joss-reviews/issues/1277#issue-413844605)

[casperdcl]

correction just released v4.32.1 with a minor bugfix

[cMadan]

@whedon set 10.5281/zenodo.2800317 as archive

[whedon]

OK. 10.5281/zenodo.2800317 is the archive.

[cMadan]

@whedon set v4.32.1 as version

[whedon]

OK. v4.32.1 is the version.

[cMadan]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

```Reference check summary:

OK DOIs

• 10.5281/zenodo.595120 is OK
• 10.1007/978-1-4842-3285-9_5 is OK
• 10.1039/C8SC03077D is OK
• 10.3847/1538-3881/aa9751 is OK
• 10.1016/j.cpc.2018.05.024 is OK
• 10.1080/17477778.2018.1473909 is OK
• 10.5334/jors.125 is OK
• 10.1186/s13321-018-0258-y is OK
• 10.1242/bio.018713 is OK

MISSING DOIs

• None

INVALID DOIs

• None
  ```

[whedon]

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/691

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/691, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

[cMadan]

@openjournals/joss-eics, I think we're all set to accept here!

[labarba]

👋 @casperdcl — Could you edit the metadata of the Zenodo deposit, so the title and author list matches the paper? You may also want to add your ORCID.

[casperdcl]

@labarba done I think

[arfon]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

```Reference check summary:

OK DOIs

• 10.5281/zenodo.595120 is OK
• 10.1007/978-1-4842-3285-9_5 is OK
• 10.1039/C8SC03077D is OK
• 10.3847/1538-3881/aa9751 is OK
• 10.1016/j.cpc.2018.05.024 is OK
• 10.1080/17477778.2018.1473909 is OK
• 10.5334/jors.125 is OK
• 10.1186/s13321-018-0258-y is OK
• 10.1242/bio.018713 is OK

MISSING DOIs

• None

INVALID DOIs

• None
  ```

[whedon]

Check final proof :point_right: https://github.com/openjournals/joss-papers/pull/694

If the paper PDF and Crossref deposit XML look good in https://github.com/openjournals/joss-papers/pull/694, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.
@whedon accept deposit=true

[arfon]

@whedon accept deposit=true

[whedon]

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

[arfon]

@GregaVrbancic, @Benjamin-Lee - many thanks for your reviews here and to @cMadan for editing this submission ✨

@casperdcl - your paper is now accepted into JOSS and the DOI is https://doi.org/10.21105/joss.01277 :zap::rocket::boom:

[whedon]

:tada::tada::tada: Congratulations on your paper acceptance! :tada::tada::tada:

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

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

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

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

This is how it will look in your documentation:

We need your help!

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: http://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://numfocus.salsalabs.org/donate-to-joss

[casperdcl]

thanks @cMadan @arfon - the metadata associated with the DOI doesn't actually match the submission well; could you update it? Specifically the bibtex fields:

author={{da Costa-Luis}, Casper O.},
title={{tqdm}: A Fast, Extensible Progress Meter for Python and {CLI}},

[arfon]

@casperdcl - I've updated the author metadata in the Crossref submission, those changes should be corrected in the next few hours.

[lrq3000]

Hello,

I come late to the party, but I strongly disagree with what @casperdcl did. And for how this paper submission was handled. I will keep it short, as these points should be self-explanatory:

1. Although he did write the paper on its own, and thus deserves credit, he did NOT contact beforehand any of the main co-developers of the software, which I am only one (I think major, but nevertheless only one) of the many contributors who could make this happen. They also deserved to be invited to contribute to the paper, and to get due credit. At the very least, they should be mentioned in an Acknowledgements section, regardless of whether they would have contributed to the paper or not.
2. Casper is not even the original author. Although we had a hard time reaching the original author, for publishing, we ought to try harder before publishing a paper. I can not even find a mention of his name: Noam Yorav-Raphael. His original repository still lives here. That is highly unethical.
3. A lot (most?) of the foundational code leading to the current form of tqdm was made by me (in particular the object-oriented approach which was initially dismissed by Casper and was necessary for most use cases tqdm can cover nowadays). Most features that were implemented after I departed (because of a change of to a more restrictive license Casper forcefully did on his own), such as tqdm_auto, and which now profit from a quite popular recognition were initially proposed by me, and were pushed/slowed down by Casper (another reason I left development).

Side-note: don't just look at the commits, but at the PR from where they come from, Casper had the habit of always merging himself without properly attributing to the real author due to a misconfiguration of the git client (at least that's what I thought, but I can see from the current history that there are still no attributions to other devs nowadays).

And I can probably raise up some other points, but this is I think enough to highlight some big red flags that should have been caught.

Nevertheless, I recognize Casper's dedication to the project, he's done a great work, and whatever his motives, I am glad the project is still maintained.

But an academic paper ought to be a honest work, and not a misrepresentation of the project's history to fit Casper's wish of showing this as a one-man project, stripping due recognition to fellow co-developers and taking full control as he did (including the license), all of which is highly questionable and certainly not an adequate conduct for the academic community.

Hence, the paper as it is can only be considered unethical and should either be amended with major changes notably to give due credits, or be retracted.

It's a shame, because it could have been a great opportunity to bring back on board fellow old-time developers and streighten the community's bonds around this wonderful project.

Pinging old time/foundational developers: @noamraph, @obiwanus, @kmike, @hadim.

[lrq3000]

PS: for those reading the emails notifications, please read the post on Github, I have made some changes to clarify.

[kmike]

I haven't contributed much to tqdm, and don't need any recognition for tqdm work.

However, I've been involved in a similar case in past, where a technical report was published for a piece of software (theano). See https://arxiv.org/abs/1605.02688 - it was handled in a different way - all contributions who made non-trivial fixes or improvements (so, no typo fixes) were asked for comments on the paper itself, and added as authors (if they're ok with that). It is a relatively small effort to list all people who helped, and a super-nice gesture, which still makes me smile. No way I'd be Yoshua Bengio's, Ian Goodfellow's, Xavier Glorot's, etc. co-author otherwise :)

Recognizing people who made important contributions (not me :) is a must though, regardless of when these contributions happened, especially if that's the first technical report. As I recall, for Theano there were several papers, separated by a few years - in this case I think that's fine to give recognition only to people who contributed since the last report, and cite previous work.

[casperdcl]

Hello, just like to say I'm happy to hear from @lrq3000 but must clear up a few points.

I come late to the party [...] Although he did write the paper on its own [...] he did NOT contact beforehand any of the main co-developers [...] That is highly unethical

As far as I know, in order of first contribution, @noamraph, @hadim, @kmike, @casperdcl, and @lrq3000 were instrumental in resuscitating the current tqdm library in 2015 (https://github.com/tqdm/tqdm/pull/35). However as @lrq3000 mentions, the original author (@noamraph, original repo https://github.com/noamraph/tqdm with 35 commits, of which 11 commits (27 lines of code) survive in the current repo, making up under 1%, vis https://github.com/tqdm/tqdm#contributions) abandoned the project and has yet to accept any invites to continue maintenance. Meanwhile @kmike, @hadim, and then @lrq3000 stopped contributing, leaving me (@casperdcl) with the sole burden of maintenance. As of paper writing, it had been years since their last contribution. In particular, I had @mentioned @lrq3000 in several issues/PRs and sent several emails to him over the last couple of years which have received no response, leading me to the obvious conclusion that he'd abandoned the project too. Still wanting to acknowledge contributions and provide public incentivisation to contribute again, I explicitly @mentioned him in this review (vis https://github.com/openjournals/joss-reviews/issues/1277#issuecomment-469222023) to no avail.

I am only one [...] I think major [...] of the many contributors who could make this happen

"Make this happen" is a bit ambiguous. There are many contributors of OS projects, including tqdm. I ensure that the documentation (https://github.com/tqdm/tqdm#contributions) explicitly refers to as many as possible using dynamic updating links, avatars, tables and references. However a loose definition of "contributing" does not satisfy the JOSS requirements for authorship. Again, I reiterate that during review I also hoped that @lrq3000, being the only other arguably major contributor to current library, would rejoin.

they should be mentioned in an Acknowledgements section, regardless of whether they would have contributed to the paper or not.

I am unclear about whether an Acknowledgements section can be included, and what exactly should be in it. Perhaps simply a link to https://github.com/tqdm/tqdm#contributions? The issue is that there are many ongoing contributions from new people. For this purpose, in this review we settled on simply adding "tqdm developers" as an author of the paper; a similar tactic used in other JOSS papers.

A lot (most?) of the foundational code leading to the current form of tqdm was made by [@lrq3000] [...] which was initially dismissed by [@casperdcl] [...] features that were implemented after [@lrq3000] departed [...] were initially proposed by [@lrq3000] [...] were pushed/slowed down by [@casperdcl] (another reason [@lrq3000] left development)

I think this is a highly contestable point which I disagree with, but probably both off topic and also not worth debating given my response above.
I'd like to make it clear that I would've always been willing to discuss project directions or reservations of contributors. The statements above are completely surprising to me. Note that an incredibly widely used project (millions of downloads per month; often in the world's top 10 Python packages) needs a very pedantic level of care and attention to detail to avoid breaking changes that could affect millions. This makes review slow and frustrating (both for maintainers and contributors) but I don't see how it could concern JOSS editors.

change of to a more restrictive license [@casperdcl] forcefully did on his own

This is not true. This being said, again I fail to see how this could concern JOSS editors.

There's a long history of debate and discussion over licensing, initially kicked off by a very concerning commit message slipped through by a minor contributor. I had changed the licence to negate any negative consequences. Subsequently, @hadim, @kmike, @lrq3000 and I actively participated in discussion (both on public GitHub issues https://github.com/tqdm/tqdm/pull/124, https://github.com/tqdm/tqdm/issues/121 and via private emails) and eventually settled upon the current licence together. This included explicit public confirmation from @lrq3000. The so-called resulting "more restrictive licence" is FLOSS so cannot be called restrictive.

[@casperdcl] had the habit of always merging himself without properly attributing to the real author due to a misconfiguration of the git client [...] but [...] can see from the current history that there are still no attributions to other devs nowadays

This is absolutely not true in any way.

I'd suggest the editors ask for evidence to backup this claim or politely request for it to be formally retracted.

I can think of only one instance where a PR by @lrq3000 was mysteriously closed without the option to re-open (https://github.com/tqdm/tqdm/pull/321), and in that case the replacement (https://github.com/tqdm/tqdm/pull/543) explicitly mentioned this fact.

In addition, I frequently agree with a contributor's ideas but (having in-depth knowledge as the sole maintainer) disagree with implementation. In these cases I have always made it a point to add my own correctional commits to PRs rather than outright remove original author's contributions. In cases where forked PRs do not "allow commits from maintainers", I go out of my way to rebase/cherry-pick commits onto a local branch, once again so that people can show up in https://github.com/tqdm/tqdm/graphs/contributors.

You can also see from https://github.com/tqdm/tqdm/commits/master?before=cc53d86f86cef63ba8dbbfb8e9cb27d4f247fd20+70 that original PR authors do indeed show up because of my maintenance efforts.

And I can probably raise up some other points

I strongly encourage you to raise any and all reservations you believe to be valid in the interest of transparency and fruitful discussion.

[@casperdcl]'s wish of showing this as a one-man project, stripping due recognition to fellow co-developers and taking full control

Again, absolutely defamatory and I must insist on a retraction. Even if I had no claim to authorship whatsoever, any claims to know what my "wishes" are are completely speculative and unfounded.

a great opportunity to bring back on board fellow old-time developers and streighten the community's bonds around this wonderful project.

For avoidance of doubt I would like to state that this was always precisely my intention. Given that there has been some responses in this review (however delayed and negative) I think this has actually been somewhat successful.

PS: for those reading the emails notifications, please read the post on Github, I have made some changes to clarify.

Please do mention if any points are missing responses.

[@kmike] [has] been involved in a similar case in past [...] all contributions who made non-trivial fixes or improvements [...] were asked for comments on the paper itself, and added as authors (if they're ok with that).

I'm not sure about the definition of "non-trivial" but this sounds like something this journal may potentially consider adding to their guidelines in future.

I would also be happy to retrospectively change this paper too upon request.

I leave the decision (if any) to the editors and sympathise that the question of authorship and acknowledgements (paper writer, code contributor, major contributor, dev, co-dev, etc) is a complex issue.

---

Finally, in case the current tqdm master branch (https://github.com/tqdm/tqdm/commit/cc53d86f86cef63ba8dbbfb8e9cb27d4f247fd20):

tqdm (master)$ git fame -wMC
Blame: 100%|██████████| 77/77 [00:02<00:00, 27.81file/s]
Total commits: 1259
Total ctimes: 1335
Total files: 203
Total loc: 2869

| Author | loc | coms | fils | distribution |
|:---------------------------|------:|-------:|-------:|:----------------|
| Casper da Costa-Luis | 2234 | 851 | 66 | 77.9/67.6/32.5 |
| Stephen Larroque | 369 | 202 | 23 | 12.9/16.0/11.3 |
| Matthew Stevens | 31 | 3 | 2 | 1.1/ 0.2/ 1.0 |
| Noam Yorav-Raphael | 27 | 11 | 8 | 0.9/ 0.9/ 3.9 |
| Guangshuo Chen | 23 | 18 | 6 | 0.8/ 1.4/ 3.0 |
| Hadrien Mary | 17 | 31 | 10 | 0.6/ 2.5/ 4.9 |
| Mikhail Korobov | 16 | 11 | 7 | 0.6/ 0.9/ 3.4 |
| Daniel Panteleit | 14 | 2 | 2 | 0.5/ 0.2/ 1.0 |
| Kyle Altendorf | 13 | 31 | 3 | 0.5/ 2.5/ 1.5 |
| Ivan Ivanov | 10 | 11 | 3 | 0.3/ 0.9/ 1.5 |
| Martin Zugnoni | 10 | 3 | 3 | 0.3/ 0.2/ 1.5 |
| Matthew D. Pagel | 8 | 3 | 3 | 0.3/ 0.2/ 1.5 |
| Marcel Bargull | 7 | 6 | 2 | 0.2/ 0.5/ 1.0 |
| Hugo | 5 | 2 | 5 | 0.2/ 0.2/ 2.5 |
| Greg Gandenberger | 5 | 1 | 2 | 0.2/ 0.1/ 1.0 |
| Min ho Kim | 5 | 1 | 5 | 0.2/ 0.1/ 2.5 |
| Veith Röthlingshöfer | 5 | 1 | 2 | 0.2/ 0.1/ 1.0 |
| Thomas A Caswell | 4 | 1 | 4 | 0.1/ 0.1/ 2.0 |
| immerrr | 4 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| James E. King III | 4 | 1 | 3 | 0.1/ 0.1/ 1.5 |
| Johannes Hansen | 3 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| Max Nordlund | 3 | 2 | 3 | 0.1/ 0.2/ 1.5 |
| Adnan Umer | 3 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| Antony Lee | 3 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| Orivej Desh | 3 | 2 | 1 | 0.1/ 0.2/ 0.5 |
| Charles Newey | 3 | 3 | 2 | 0.1/ 0.2/ 1.0 |
| Mike Kutzma | 2 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| zz | 2 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| Kuang-che Wu | 2 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| David W.H. Swenson | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| Jesus Cea | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| shongololo | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| Alexander | 2 | 2 | 2 | 0.1/ 0.2/ 1.0 |
| Julien Chaumont | 2 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| Yaroslav Halchenko | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| Tomas Ostasevicius | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| RedBug312 | 2 | 2 | 1 | 0.1/ 0.2/ 0.5 |
| ReadmeCritic | 2 | 1 | 2 | 0.1/ 0.1/ 1.0 |
| William Turner | 2 | 1 | 1 | 0.1/ 0.1/ 0.5 |
| James Lu | 2 | 3 | 2 | 0.1/ 0.2/ 1.0 |
| Igor Ljubuncic | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| stonebig | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| FichteFoll | 1 | 2 | 1 | 0.0/ 0.2/ 0.5 |
| Sergei Izmailov | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Cheng Chen | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Staffan Malmgren | 1 | 2 | 1 | 0.0/ 0.2/ 0.5 |
| Darin | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Todd | 1 | 2 | 1 | 0.0/ 0.2/ 0.5 |
| Peter VandeHaar | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Anurag Pandey | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Robert Krzyzanowski | 1 | 1 | 1 | 0.0/ 0.1/ 0.5 |
| Alex Rothberg | 1 | 2 | 1 | 0.0/ 0.2/ 0.5 |
| Rafael Lukas Maers | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Jan Schlüter | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Lev Velykoivanenko | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Pablo Zivic | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Albert Kottke | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Edward Betts | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Jack McCracken | 0 | 2 | 0 | 0.0/ 0.2/ 0.0 |
| JoshKarpel | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Dyno Fu | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Socialery | 0 | 2 | 0 | 0.0/ 0.2/ 0.0 |
| Jose Tiago Macara Coutinho | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Arun Persaud | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Andrey Portnoy | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Riccardo Coccioli | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| David Bau | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Ford Hurley | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| zed | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Dénes Türei | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Shirish Pokharel | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |
| Fabian Dill | 0 | 2 | 0 | 0.0/ 0.2/ 0.0 |
| Javi Merino | 0 | 1 | 0 | 0.0/ 0.1/ 0.0 |

[arfon]

@lrq3000 @kmike - thank you for reporting this issue. We're going to conduct our own investigation and report back our findings. Given JOSS is run by a volunteer editorial team this may take a few weeks.

Arfon Smith
Editor-in-Chief, JOSS

[arfon]

Please note that I'm also locking this issue for now while we investigate the claims here. Anyone wishing to provide further information related to this submission should email me directly on arfon.[email protected]

[arfon]

Dear @casperdcl, @lrq3000, @noamraph and other tqdm contributors. The JOSS editorial board has considered the concerns raised by @lrq3000 and agree the authorship of this paper is problematic. JOSS’s policy on authorship states:

Author lists must be correct and complete. All listed authors must have made a contribution to the work, and all significant contributors should be included in the author list.

While we recognize that @casperdcl made an attempt to include @lrq3000 as an author after @GregaVrbancic identified @lrq3000’s contributions during their review, we’ve concluded that this effort was insufficient and therefore a violation of JOSS’s ethical standards.

How we plan to handle this submission

We ask that the tqdm contributors resolve this authorship question between yourselves and report back here on the agreed resolution. Past submissions have successfully used a public thread on their repository (e.g., an issue posted on https://github.com/tqdm/tqdm) inviting past authors to be authors.

If no acceptable resolution can be found then we will retract this paper in one calendar month from today (25 February 2020).

Should the tqdm team arrive at an acceptable solution then we would handle the paper update as follows:

• Retract the original paper.
• Publish a new tqdm JOSS paper with the updated author list/acknowledgements. This paper will be fast-tracked through the review process (likely a quick review by one or more of our editors).
• Ensure that the Crossref metadata associated with the new paper includes a isVersionOf identifier making it clear that the new paper is a version of the earlier record (https://doi.org/10.21105/joss.01277).

Which of the tqdm contributors should be included on this paper?

Deciding authorship can be challenging and ultimately authors need to decide this between themselves. That said, in this situation, the JOSS editorial team expects any resolution here to include the explicit consent of @casperdcl, @lrq3000, & @noamraph.

We trust this is an acceptable solution for all parties involved. JOSS is a civilized platform, and we value civility in resolving disputes. If in this one-month window the tqdm contributors are able to resolve the co-authorship issue, peacefully and amicably, then an updated version of this submission can be published in place of the current version, which will be retracted. If not, then we will be forced to retract this paper with no replacement.

Arfon Smith on behalf of the JOSS editorial team.

[hadim]

I guess I am kind of late to the party. I am the person who forked the original repo to tqdm/tqdm and maintained it for a few weeks before I let the other devs taking over.

I am not sure I should be on that paper but at least my name should be cited in it wherever it's in an acknowledgment paragraph or a an history paragraph about the birth and re-birth of the project (this section would be cool to have actually).

That being said, maybe we should continue that discussion at https://github.com/tqdm/tqdm.

[arfon]

That being said, maybe we should continue that discussion at https://github.com/tqdm/tqdm.

Yes, please discuss this topic in https://github.com/tqdm/tqdm and report back here when you have a resolution.

[casperdcl]

@arfon thanks for your time and review.

the JOSS editorial team expects any resolution here to include the explicit consent of @casperdcl, @lrq3000, & @noamraph.

Clearly we shouldn't have any issues with @lrq3000 (and @hadim/@kmike) going forward but I'm concerned about @noamraph - I've never managed to contact him and as far as I know nobody else has either, despite very serious efforts (year ago, we were about to rename the project - https://github.com/tqdm/tqdm/issues/2, https://github.com/tqdm/tqdm/issues/30, https://github.com/tqdm/tqdm/issues/33, and eventually PyPI admins granted access to the old project). If you also look at https://github.com/tqdm/tqdm/issues?q=involves%3Anoamraph you'll see there's no participation either.

Given the current ~1% code contribution, nonexistent website/wiki/paper/testing/framework contribution, and last contribution dating back to Jan 2014, would it be an issue if we get no response?

[lrq3000]

Yes we can surely work it out together.

About Noam, the total code contribution is irrelevant IMO in his case as he invented the very foundation and concept of this project, so the code quantity is irrelevant in his case.

But indeed he may be hard to reach, although I'll try my best to. In the worst case, if he cannot be reached despite our best attempts, I propose Noam to be in any case at least mentioned in context of the introduction or a history section. Would this be a ok solution for the JOSS board?

(typed on phone, sorry for eventual typos)

[arfon]

Clearly we shouldn't have any issues with @lrq3000 (and @hadim/@kmike) going forward but I'm concerned about @noamraph

I’ve actually heard directly from @noamraph over email twice in the last couple of days. In these emails @noamraph expressed an interest in authorship. I will ask him to participate directly in this discussion.

[noamraph]

Hi all, I apologize for being so unresponsive, and for the trouble this has caused. Anyway, thankfully I'm alive, and I'll try to be more responsive now.

[lrq3000]

Dear @noamraph, I am very pleased and honored to talk with you, that's awesome! I will open an issue on tqdm repo before tomorrow with some propositions so we can further discuss there. Thank you for coming in and no worries about the time! :D

[noamraph]

Thank you @lrq3000! You're making me blush...

[casperdcl]

Hello everyone. Thank you for your patience!

After much discussion I think we're all confident that we can arrive at a conclusion.

However before I can contribute I need to understand JOSS principles/ethos so that I can then follow them. I need an answer to this hypothetical question:

A FOSS project Proj exists. SC-A is a significant contributor to Proj. SC-A invites all other significant contributors of Proj to collaborate on a JOSS paper Pap. Everything goes smoothly apart from SC-B. Everyone agrees SC-B is a significant contributor to Proj. However SC-B states that they have no time to write or review Pap, but still would like to be listed as an author of Pap. All significant contributors of Proj non-negotiably refuse to volunteer any opinions on the matter, and insist that JOSS decide.

Question: should SC-B be listed as an author?

1. JOSS official answer: :tada: Yes
2. JOSS official answer: :rocket: No
3. JOSS official answer: :confused: None/undecided
   
   
   
   • In this case JOSS must reject the paper as everyone else has refused to decide.
   
   

Please note I will personally fully support JOSS without argument/debate no matter what answer is picked - it is fully within its rights to pick any. It's also a hypothetical question so any answer is not taken to be a decision on this issue.

Feel free to vote using emoji

[danielskatz]

If all other authors are ok with SC-B being listed as an author without writing or reviewing the paper, and SC-B is willing to have their name on something they didn't review, then from the point of view of JOSS, I think the answer is that SC-B should be listed as an author, as that would be a conclusion that would satisfy all authors ad give credit to all authors. (With the caveat that I can't advise that SC-B should be willing to have their name on something they didn't review.)

If other authors disagree, then I don't think JOSS can force agreement.

[arfon]

If all other authors are ok with SC-B being listed as an author without writing or reviewing the paper, and SC-B is willing to have their name on something they didn't review, then from the point of view of JOSS, I think the answer is that SC-B should be listed as an author, as that would be a conclusion that would satisfy all authors ad give credit to all authors.

👍 I agree with this assessment.

[danielskatz]

Are we ready to proceed with this?

[casperdcl]

yes will PR soon

[casperdcl]

PR here: https://github.com/tqdm/tqdm/pull/905

[danielskatz]

who will merge this?

[casperdcl]

one of the assignees when everyone's happy

[casperdcl]

@whedon generate pdf from branch paper

[whedon]

Attempting PDF compilation from custom branch paper. Reticulating splines etc...

[lrq3000]

I'm sorry but please wait a few more days. Seeing how many people refused
to be co authors, i realized that it would be more ethical and safer to ask
everyone if they want to be a co-author. I'll ping them in a hour and in
48h we can wrap this up.

Le mer. 4 mars 2020 à 18:04, whedon [e-mail] a écrit :

Attempting PDF compilation from custom branch paper. Reticulating splines etc...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1277?email_source=notifications&email_token=AAIRFXVA3K73OIRPCG5QCOTRF2CZ7A5CNFSM4GZ2TCJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENY53VY#issuecomment-594664919,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIRFXS4OPSWZBEWYQAOFH3RF2CZ7ANCNFSM4GZ2TCJQ
.

[arfon]

Dear authors and reviewers

We wanted to notify you that in light of the current COVID-19 pandemic, JOSS has decided to suspend submission of new manuscripts and to handle existing manuscripts (such as this one) on a "best efforts basis". We understand that you may need to attend to more pressing issues than completing a review or updating a repository in response to a review. If this is the case, a quick note indicating that you need to put a "pause" on your involvement with a review would be appreciated but is not required.

Thanks in advance for your understanding.

_Arfon Smith, Editor in Chief, on behalf of the JOSS editorial team._

[arfon]

:wave: @casperdcl @lrq3000 - I realize times are challenging for lots of people right now but I wanted to check in to see if you think this conversation about authorship has converged?

[casperdcl]

dropped off my radar but I think I've responded to all the authorship/affiliation requests in https://github.com/tqdm/tqdm/issues/887 with :+1: and corresponding checkboxes in https://github.com/tqdm/tqdm/pull/905, don't think I've missed anything, haven't heard anything so perhaps could just merge?

[lrq3000]

Hello guys, yes sorry it's my fault, i still need to take a look just to
see if we didn't forget (or add without consent) anyone. I am behind my
schedule with all that's happening right now. I'll tabe a look on
Wednesday, but Casper did an amazing job so if he says it's fine to merge
then I trust him and would agree to the merge if you guys want it done now.

Thanks a lot Arfon, Casper, and everyone who was involved for your great
help.

Take care and stay safe.

Le lun. 27 avr. 2020 à 23:28, Casper da Costa-Luis [e-mail]
a écrit :

dropped off my radar but I think I've responded to all the
authorship/affiliation requests in tqdm/tqdm#887
https://github.com/tqdm/tqdm/issues/887 with 👍 and corresponding
checkboxes in tqdm/tqdm#905 https://github.com/tqdm/tqdm/pull/905,
don't think I've missed anything, haven't heard anything so perhaps could
just merge?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openjournals/joss-reviews/issues/1277#issuecomment-620245222,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAIRFXUU6T5AKDCSV632EODROX2JBANCNFSM4GZ2TCJQ
.

[casperdcl]

argh just realised there's also https://github.com/tqdm/tqdm/pull/910 and https://github.com/tqdm/tqdm/pull/911

[lrq3000]

Ok I've done the review, I have just made one comment that needs your attention @casperdcl and after it's fine on that side. I'll take a look at those 2 other PRs if I can do something. Thank you again for your great work!

[arfon]

Ok I've done the review, I have just made one comment that needs your attention @casperdcl and after it's fine on that side. I'll take a look at those 2 other PRs if I can do something. Thank you again for your great work!

:wave: @lrq3000 @casperdcl - any chance we can wrap this up this week?

[lrq3000]

@arfon I am available this week to do anything necessary, I will reply asap. At this point, I think there's little left to do, we just need @casperdcl 's opinion on the matter.

[casperdcl]

just managed to squeeze in some time to merge in some urgent PRs; will add this to my list of weekend chores - hopefully will happen soon.

[arfon]

OK thanks for the updates both.

[casperdcl]

Ok I think we've reached an impasse. All issues have been resolved except a question of ordering names. The relevant comments are https://github.com/tqdm/tqdm/pull/905#issuecomment-640124258 and https://github.com/tqdm/tqdm/pull/905#issuecomment-640164461.

Essentially (correct me if I'm wrong):

• the Journal refuses to define & enforce a definition of paper authorship
• the contributors of the library have refused to agree on a definition of paper authorship

[lrq3000]

Just a suggestion about this:

the contributors of the library have refused to agree on a definition of paper authorship

With paper authorship, we are working with "human material", so I think a formal definition may not always be possible. But if we can reach a consensus on the authors order, even without a formal definition behind, that would be good enough IMO.

I added a reply with some additional metrics, I hope this may resolve or at least help the issue progress.

[arfon]

@casperdcl @lrq3000 thank you for all of the work you've done to date to try and resolve this issue. I've been trying to keep up to date with progress over the past few months (e.g. in https://github.com/tqdm/tqdm/pull/905) and I have to say I'm not exactly sure how close this is to coming to a resolution.

It it now nearly six months since the authorship issue was raised here, and my comment stating how JOSS planned to handle this.

I recognize that the last few months have been truly exceptional circumstances for many, and as a result we have given this issue significantly more time to resolve itself than originally planned. That said, we absolutely must reach a conclusion _eventually_ and I believe this time has come.

I would like to see a resolution to this within the next two weeks (Saturday 1st August 2020) with explicit agreement from both @casperdcl and @lrq3000 that a mutually agreeable outcome has been reached. As we stated before, if no acceptable resolution can be found then we will retract this paper on the 2nd August 2020 and the JOSS website will reflect this retraction (see this paper as an example: https://joss.theoj.org/papers/10.21105/joss.01338).

[arfon]

@whedon remind @arfon in two weeks

[whedon]

@arfon doesn't seem to be a reviewer or author for this submission.

[lrq3000]

Thank you very much @arfon and the Joss team for your understanding and for allowing us so much time to resolve this issue.

Ok I agree with the deadline and the conditions. I will discuss with @casperdcl directly.

[casperdcl]

Thanks all for your input/responses.

I have been careful to avoid volunteering any personal opinions as much as possible. However, in the interest of clarity and to hopefully help understand my reasoning, these are my working assumptions (aka what I believe to be irrefutable facts):

Everyone

• users who have copyright over the codebase: complex, many and various; a good guide is https://github.com/tqdm/tqdm/graphs/contributors or https://doi.org/10.5281/zenodo.595120. However, specifics are not concerning to end-users due to the FOSS licence(s) associated with the code. The fact that this is not a concern is evident by the millions of weekly downloads
• original copyright holder and sponsor/funder of the initial version of the codebase pre-open sourcing: as yet unnamed company which @noamraph worked/works for
• users who have copyright over the original publication: @casperdcl
• users who have made valuable contributions to the original publication, but do not assert copyright (aka reviewers): @GregaVrbancic, @Benjamin-Lee
• users who have copyright over the proposed revised publication: @casperdcl
• users who have made valuable contributions to the proposed revised publication, but do not assert copyright (aka revision reviewers): @hugovk, @lrq3000

JOSS

• unlike most (if not all) other journals, JOSS does not enforce a strict definition of authorship (c.f. IEEE's definition)
• JOSS does not have a prominent warning about this surprising difference to advise submitters and readers of this unexpected difference from their assumptions. If would be both prudent and ethical to add such a warning at the very least to its submission guidelines
• true to its principles, JOSS has stated it does not want to make a decision about the authorship list of this proposed revised publication

Summary

Based on the following facts:

• JOSS has stated it would like, in general, authors to agree on the author list
• JOSS has stated it would like, in this case, @casperdcl and @lrq3000 to agree on the author list
• JOSS has stated it would like, in general, Zenodo author lists (which are automatically determined code contributors) to at least temporarily match publication author lists
• Everyone has stated that they would accept any final decision made by JOSS even if they don't feel happy about it

it would seem highly likely that JOSS would consider the following outcome acceptable:

• authors of the revised publication: @casperdcl, @lrq3000
• contributors (listed in the revised publication either at the top or in the acknowledgements): everyone I've made the effort to add currently; i.e. all codebase contributors minus the ones who have opted out, vis. https://github.com/tqdm/tqdm/pull/905. Order determined by Zenodo, GitHub, git-fame or even popular sentiment (e.g. "mention @noamraph and his company first")
• reviewers of the revised publication: @GregaVrbancic, @Benjamin-Lee, @hugovk, @lrq3000

[lrq3000]

I was not aware of this new proposition before and it is a total change from the previous proposition which we have worked on up to now. I will comment more later.

[casperdcl]

Ah this is not a "new proposal". It's firstly not "new" as it was actually the first suggestion, I think. Secondly it's not a "propsal," it is only my private thoughts (aka "working assumptions").

The "proposal" is still simply https://github.com/tqdm/tqdm/pull/905 as-is

[arfon]

Thanks for the quick responses @casperdcl and @lrq3000. For clarity (and for future readers) I would like to provide some additional thoughts/responses to what has been said:

@casperdcl said:

unlike most (if not all) other journals, JOSS does not enforce a strict definition of authorship (c.f. IEEE's definition)

While I agree IEEE does have a formal definition, many journals are much less formal about this _because authorship is such a complex topic with many nuances_.

For software journals, the issue of authorship has the added complexity of having to accommodate contributions to the software. For JOSS and its short papers, essentially the _majority_ of the effort behind a contribution (paper + software) resides in the software by design.

JOSS does talk about authorship however. In our ethics guidelines (https://joss.theoj.org/about#ethics) we say:

• Author lists must be correct and complete. All listed authors must have made a contribution to the work, and all significant contributors should be included in the author list.

...and in our reviewer docs (https://joss.readthedocs.io/en/latest/review_criteria.html#authorship) we state:

As discussed in the submission guidelines for authors, authorship is a complex topic with different practices in different communities. Ultimately, the authors themselves are responsible for deciding which contributions are sufficient for co-authorship, although JOSS policy is that purely financial contributions are not considered sufficient.

I should point out that over the past ~4 years, JOSS has published nearly 1000 papers and this is _the only one_ where authors have struggled to reach an amicable solution. This to me suggests the issue resides with this submission rather than some deficiency in our guidelines.

JOSS has stated it would like, in this case, @casperdcl and @lrq3000 to agree on the author list.

I should clarify that I suggested this because my personal read of https://github.com/tqdm/tqdm/pull/905 was that @lrq3000 had been doing a good job of representing the group opinion over there. Specifically I believe the suggestion made in https://github.com/tqdm/tqdm/pull/905#issuecomment-599143376 by @lrq3000 to have the first three authors be: Casper da Costa-Luis, Stephen Karl Larroque, and Noam Yorav-Raphael seems very reasonable.

To remove any ambiguity here, given @noamraph's comment in https://github.com/tqdm/tqdm/pull/905#issuecomment-640164461, I revise my previous comment to be that we require approval of @casperdcl, @lrq3000, and @noamraph for any modified author list.

With a slight modification to @casperdcl's suggestion above I am providing the following suggested outcome:

• Authors of the revised publication: @casperdcl, @lrq3000, @noamraph
• Contributors (listed in the revised publication either at the top or in the acknowledgements): everyone @casperdcl made the effort to add currently; i.e. all codebase contributors minus the ones who have opted out, vis. tqdm/tqdm#905. Order determined by Zenodo, GitHub, git-fame or even popular sentiment.
• Reviewers of the revised publication: @GregaVrbancic, @Benjamin-Lee, @hugovk, @lrq3000

If you agree with this resolution please provide your revised list of authors in the form of a change to the paper.md by 2nd August 2020. As I stated before, we regret that if there isn’t an agreed resolution between @casperdcl, @lrq3000 & @noamraph by then, we will have to retract the paper.

[lrq3000]

Dear @arfon,

Thank you very much for the clarification. I agree with the suggested outcome, and I think most contributors explicitly stated they would agree with this potential scenario with a reduced set of authors and others in contributors. We will continue working on https://github.com/tqdm/tqdm/pull/905 and reach a conclusion under the stated deadline.

I just have one question: you mention that contributors can be listed at the top, is there an example of this in another publication? I think it would be a very nice option for us.

[lrq3000]

@arfon re about contributors listed at the top: is this what you had in mind? (it's just a draft to test what it would look like, we'll work on it with the other co-authors and contributors anyway :-) )

[arfon]

Great, thanks @lrq3000!

Yes, that draft paper looks good to me.

[lrq3000]

@arfon Thank you, it looks good to me too!

About the list of contributors, you suggested "all codebase contributors minus the ones who have opted out". The contributors who have opted out did opt out of co-authorship, but not necessarily of acknowledgement (some who opted out even mentioned they would agree to/prefer an acknowledgement).

Do you think it would be OK if we (the 3 co-authors) decide to include all contributors in the end?

[arfon]

Do you think it would be OK if we (the 3 co-authors) decide to include all contributors in the end?

Yes, I'm happy for you all to figure this out between yourselves.

[arfon]

In May 2019, JOSS published this paper tqdm: A Fast, Extensible Progress Meter for Python and CLI.

While potential authorship issues were noted by reviewers at the time and an attempt was made by the submitting author to contact one of the other major contributors to the package, JOSS published the paper as a single-author paper.

Sometime later, the authorship (and JOSS handling) of this submission was flagged as problematic by a major contributor to the software and JOSS conducted an internal review, and concluded that there had been an ethical violation and offered the tqdm community one month to resolve the authorship issue.

Due to the challenges associated with the COVID-19 pandemic, JOSS did not hold the tqdm community to the original deadline of the 25th February 2020, instead setting a new deadline on the 18th July 2020 for a resolution to this by 1st August 2020.

Unfortunately, even after significant efforts from all parties, the tqdm community have been unable to resolve this issue and come to an agreed set of authors for their paper.

As a result, with regret, JOSS is today retracting this submission due to a violation of its ethical standards.

Arfon Smith (EiC JOSS) on behalf of the JOSS editorial team.