Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update paper #887

Open
casperdcl opened this issue Jan 26, 2020 · 94 comments · May be fixed by #905
Open

update paper #887

casperdcl opened this issue Jan 26, 2020 · 94 comments · May be fixed by #905
Assignees
Labels
question/docs ‽ Documentation clarification candidate

Comments

@casperdcl
Copy link
Sponsor Member

Discuss updating paper (archived at https://doi.org/10.21105/joss.01277) as per openjournals/joss-reviews#1277.

@casperdcl casperdcl added the question/docs ‽ Documentation clarification candidate label Jan 26, 2020
@casperdcl
Copy link
Sponsor Member Author

casperdcl commented Jan 26, 2020

In an attempt to avoid any debate (so we can focus on tackling other open issues), hopefully we can get an immediate decision:

Reading the editor-in-chief's comments very carefully, in particular where and when others are @mentioned, the impression I get is he has done some research and may be implying authors: @casperdcl, @lrq3000, tqdm developers; acknowledgements: @noamraph. I might be wrong and it would be great if @arfon could confirm either way. Further I would suggest (as per @hadim's request) to also add @hadim in the acknowledgements. I would also suggest adding @kmike if he is amenable. I am unsure about adding others but will not refuse any suggestions.

To further prompt a decision:

  1. I reiterate my willingness to accept the editorial team's decisions.
  2. I think one of the main responsibilities of a journal is to (with the aid of/via the reviewers and editorial team) define and make decisions on authorship.

I understand that is a big request with a lot of responsibility and research associated, especially considering the voluntary nature of the JOSS team's work. However I would very much appreciate if at least a suggestion if not a decision is provided.

@noamraph
Copy link
Contributor

Hi! Here I am!

Arfon wrote: "all significant contributors should be included in the author list." I consider myself to be a significant contributor, by writing the initial working version. I acknowledge that a lot of significant work has been done since, probably with much more time spent than my initial effort. However, I still consider myself to be a significant contributor.

Cheers,
Noam

@casperdcl
Copy link
Sponsor Member Author

casperdcl commented Jan 26, 2020

Hey @noamraph,

Happy to hear from you.

Unfortunately though in this instance I disagree for a long list of reasons. However I really hope to avoid or at least shorten any debate (whatever the outcome) if we could get a response from @arfon here...

@arfon
Copy link

arfon commented Jan 26, 2020

@casperdcl, @lrq3000, tqdm developers; acknowledgements: @noamraph. I might be wrong and it would be great if @arfon could confirm either way.

Apologies if this is how my comment was interpreted, this is not what I was trying to imply because...

I think one of the main responsibilities of a journal is to (with the aid of/via the reviewers and editorial team) define and make decisions on authorship.

I disagree. The journal's responsibility is to ensure that there has been ethical behaviour on the part of authors, reviewers, and editors. It it not the responsibility of the journal to decide who should be an author on a given paper. As I said in this comment authorship is a challenging subject and something that the authors/contributors of the package are best-placed to decide between themselves.

To be absolutely clear here I think if @noamraph wants to be an author, he should be.

Hopefully this is useful additional context. I am hoping this additional input from myself will be sufficient to guide you all in your decision. As I said over in openjournals/joss-reviews#1277 (comment), this is a conversation that needs to happen between you all, and really isn't something that I can/or should be steering.

@arfon
Copy link

arfon commented Jan 26, 2020

Hi all, I'd like to introduce @gkthiruvathukal who is a member of the JOSS editorial team. @gkthiruvathukal has kindly volunteered to act as a neutral mediator/third party in these discussions. As past Editor in Chief of CiSE he has a wealth of experience with discussions such as these.

@gkthiruvathukal
Copy link

@arfon Thanks for the introduction. I've taken the time to look at tqdm. It's great to see all of the work that has gone into this effort. As the neutral mediator (and observer in general) I'd like to encourage us to start from the git fame output shown on the landing page.

The git fame output shows that there are multiple contributors who probably should be recognized as co-authors, per JOSS guielines. I've done some preliminary analysis below.

Strong case for co-authorship:
@casperdcl
@lrq3000
@noamraph

Strong case for acknowledgments and possible co-authorship:
@altendky (top 3 on git fame list, possible co-author?)
@chengs
@mjstevens777
@hadim
@hmike

Again, I remind everyone that this is coming straight from the tqdm landing page.

In Software Engineering, I teach that not all contributions can be measured by LOC or number of commits. There are multiple ways to make an impact, and sometimes an enormous amount of impact can be made without the singular focus on LOC (or commits). For example, there can be developers who write good tests, configuration scripts, and documentation. These all make for great projects, and tqdm seems to have most of the good things in SE going for itself. This project is lucky to have such a great group of contributors, and it is my hope that you all can work to understand the importance of your software being well-cited as opposed to individuals.

@arfon and I have discussed this case, and we don't want to make decisions for you. We are both in agreement that this submission needs to recognize all co-authors in order for it to remain a JOSS submission, so if you are mentioned above, perhaps you can respond (concisely) with whether you agree with the above initial analysis. If you think you should be on a different list (co-authors or acknowledgments) than my initial triage, please make this clear in your follow up. I promise to hear everyone's input and help you to reach a conclusion that is good for the project and those who have made the most significant contributions to its success. This is a nice project and is the sort of contribution we really like to see submitted to JOSS.

I'd like to see if we can bring the authorship issues to a resolution by Friday, 31 January, so JOSS can decide on the next steps, which will involve revising the submission one way or another.

@altendky
Copy link
Contributor

@gkthiruvathukal, I have no concerns with your initial groupings for attribution.

@lrq3000's comments about lack of attribution of changes had me a little worried as I remembered some funny feelings with some of my contributions. I think the primary missing part on my contributions was that two PRs showed as closed, not merged (#673, #622). The commits they were closed by do show me as author but for some reason have @casperdcl as committer. #674 (adding four words on one line...) was closed and a different solution committed without referencing me (no complaints here). #598 (my only significant contribution) was merged per normal GitHub methods. I closed #590 because I took a different approach in #598 that replaced it. I won't speak to @lrq300's issues but the only comment I would have related to mine is that it would probably be good practice to use the GitHub merge button so it shows up as merged in GitHub. It supports merge, squash-merge, and rebase so hopefully there's sufficient flexibility to satisfy personal git preferences.

Based on the infamously questionable metric of lines of code I would give @lrq3000 'author' level attribution. https://github.com/tqdm/tqdm/graphs/contributors (5220 lines compared to @casperdcl's 23,267 lines). It sounds like if I actually bothered to research it I would give 'author' level attribution for other reasons as well.

Based on being the original author (I think there isn't contention on this 'fact'?) I would give @noamraph 'author' level attribution.

Should I be an 'author'? Aside from the whole conflict of interest etc in me weighing in on credit due to me... I think it depends. Is an author someone that authored a block of code for tqdm? Or is an author someone that has contributed primary architecture or a large featureset? I certainly contributed one non-trivial bug-fix. I certainly did not design or author a significant portion of tqdm. I suspect that the sensible answer is to put me in the 'acknowledgements' group, not co-author. If I get co-author for my one bug-fix then we should look at everyone else that made non-trivial bug fixes and feature additions and include them as well.

Oh, to be complete, I'd put @casperdcl in the 'author' group as well. :] And no, I'm not going to bother to justify that.

@hadim
Copy link
Contributor

hadim commented Jan 27, 2020

I would give @noamraph, @lrq3000 and @casperdcl 'author' level.

As for me, I don't think I should choose for myself rather I will let others choose for me. That being said I am fine either way. The only thing I ask is to at least be cited in a 'history' paragraph.

My contribution to the code is much more modest than the devs I've cited above but I would like to highlight that I am the one who originally forked noamraph/tqdm repo to create tqdm/tqdm. Now to be honest I don't remember exactly everything so others please feel free to tell if I am wrong.

Quickly after the creation of tqdm/tqdm a bunch of devs showed up (including @lrq3000, @casperdcl and @kmike ) and showed a very strong interest in the project. Everyone started to open issues and create PRs and very quickly the project became very popular. I remember giving up quickly on the development after the fork and letting the other devs maintaining tqdm.

I don't know if the project would be different today without me forking it. I guess probably not, since someone would have done it anyway at some point.

That was my modest contribution to the debate. I hope everyone will get their deserved acknowledgment/authorship without any more drama :-)

@gkthiruvathukal
Copy link

@hadim and @altendky, thanks for your quick follow-up. I am going to continue observing, but my initial reaction is that you probably deserve more than an acknowledgment for your contributions as significant contributors. I always take an inclusive approach to contributions, no matter how large or small. Hopefully, the lead contributors will chime in with whether we could live with the top contributors as minor co-authors. We can easily arrange the co-authors in any order. I don't think there is much doubt about @casperdcl, @lrq3000, and @noamraph but am at this point hoping the three of them could agree to be co-authors and invite any additional authors with a strong case for inclusion.

@altendky
Copy link
Contributor

@gkthiruvathukal, agreed as far as tending towards more inclusivity. Is there something that restricts to co-authors and acknowledgments as opposed to adding a contributors group in between? I wouldn't feel slighted being 'merely' acknowledged but if there's any contention on the topic for others then perhaps more categories would help (I mean... three anyways, not 17).

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

Hello everyone! Thank you all (including Casper) so much for your feedbacks! Sorry for my delay, I tend to always spend more (too much?) time on research before doing anything :-) Thank you very very much @gkthiruvathukal and @arfon for accompanying us and your very valuable insights on this issue!

About the main issue at hand, here are my suggestions:

  • I agree we should strive to be as inclusive as possible with the end goal of being fair. If we choose not everyone to be in the paper's authors list (although there is a precedent as @kmike pointed out), there is ample space in the acknowledgements. Not only for the old-time devs, but for also the new contributors since then. But we need to define a metric indeed. Personally, I would be very glad to see our fellow co-developers in the author list!
  • @casperdcl has without any doubts contributed the most to this project, maintained it all this time making it a very successful package used in lots of other applications, and made this paper happen. I think we can all agree that he deserves to be the first author.
  • @noamraph, being the original developer who conceived the whole foundation of this project, should be an author as well (see scikit-learn for a precedent). I would suggest him to be 2nd co-author. In addition, I suggest Noam could provide valuable insights, by writing about why and how he conceived tqdm (ie, his vision), and this IMO would be a great addition to the paper.
  • as @hadim suggested in the other thread, I agree a history section would be very pertinent, and it would be an opportunity to acknowledge several developers. If not a history section, an addition to the introduction would also be fine, it depends on how we work it out. Please see the etherpad below for a rough first draft :-)

Questions that need to be resolved:

  • Arfon, you said the paper will be reviewed through a "fast-track", so @gkthiruvathukal do you know if this means we should stick with minimal modifications (ie, we shouldn't rewrite significant portions of the paper), right? Would a new History section (along with Acknowledgements) be ok?
  • How do we organize the attributions? There are three possible places:
    • In paper's authors list.
    • In paper's body in context.
    • In an Acknowledgements section.
  • In relation to the previous point, we also need to assess the contributions to the code. There are several tools for that (next I'll experiment with them). @gkthiruvathukal is there a tool (apart from git fame) you would advise to explore in more fine grained details the git history? We should also review issues since some were not properly merged in.

For efficiency, I have created an etherpad (collaborative text editor) with a rough outline of my idea of the changes we could make, so that everyone here can contribute (if there is any vandalism, I can make it private and invite manually), and it's still of course meant to change depending what we agree on:

https://board.net/p/tqdm-paper

(Please enter your name in the upper right corner, language can be changed in the settings if it's not autodetected from your browser)

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

(For those who received the email notification, I have change the URL for the pad to be in English by default, please prefer to use this URL: https://board.net/p/tqdm-paper )

@gkthiruvathukal
Copy link

Responding to @lrq3000's questions:

Q: Arfon, you said the paper will be reviewed through a "fast-track", so @gkthiruvathukal do you know if this means we should stick with minimal modifications (ie, we shouldn't rewrite significant portions of the paper), right? Would a new History section (along with Acknowledgements) be ok?

A: Yes, the modifications would be minimal, and a complete rewrite should not be necessary.

Q: How do we organize the attributions? There are three possible places: In paper's authors list, In paper's body in context, In an Acknowledgements section.

A: Speaking as an observer, I'd like to see as many authors as possible. I know tqdm is important, but let's remember that the paper with the record number of authors on LHC (Large Hadron Collider, a super important project, too) is more than 5,000 authors, https://www.nature.com/news/physics-paper-sets-record-with-more-than-5-000-authors-1.17567. Did everyone contribute equally to this paper? Did everyone even write it? Or do the actual research? We'll never know, but they're all co-authors. We have a much smaller number of potential authors here? I'd like to see as many included as possible, provided their contributions can be justified in quantitative or qualitative terms.

Q: In relation to the previous point, we also need to assess the contributions to the code. There are several tools for that (next I'll experiment with them). @gkthiruvathukal is there a tool (apart from git fame) you would advise to explore in more fine grained details the git history? We should also review issues since some were not properly merged in.

A: I continue to research on this topic, but there are no really great tools, which is why I'm doing research on software metrics (hoping to change the state of affairs). One possible way is to look at other data that might show activity. You seem to have a fairly active issue tracker. Perhaps you can look at how many members of the team helped to raise and/or resolve issues. Did any contributors help, specifically, with user-facing aspects of the software (testing, docs, etc.?)

In the end, however, this can't be left entirely to data. It comes down to team dynamics and people advocating for others who may have made significant contributions. It seems like we already have convergence on some key contributors. The question is, are there any other minor contributors who are worthy of co-authorship? I would like those in a strong position to speak for those who may not be willing to advocate for themselves. Once I see all of the responses, I will synthesize a list of co-authors. Again, I must stress that Arfon and I do not want to make the decisions for you. And similar to @lrq3000, I prefer to focus on research. Oddly, this project is helping to motivate the need for metrics, which is the subject of some of my current research. (Lest I digress.)

I won't speak to the "end game" because @arfon and the board are still discussing how to handle papers where the DOI and its metadata may need to be changed. My goal is to help mediate the (ethics) issues that were raised and help everyone to bring the matter to a graceful (and civilized) conclusion. There seems to be a lot of goodwill here, and I am pleased with the responses I have seen thus far. I'm optimistic we can come together to get the co-author list right!

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

@gkthiruvathukal Thank you so much for your again very enlightening reply! And I hope you'll get all the funding needed to pursue your goal, it would really help to have better metrics indeed ;-)

I get what you said, although I have I think a fairly good memory of what happened and all contributors (I tend to have a good memory of those things, as I am always grateful to anyone who freely spend time to help others such as in opensource projects), I don't know what happened after, so I'm now going to try to explore the history with tools and manually to get a more comprehensive view and then I'll offer suggestions :-) (this may take some time, any help is welcome, if anyone has some contributors in mind please feel free to cite them!)

@gkthiruvathukal
Copy link

Thanks for your support, @lrq3000. I had some funding for work on this topic, but it was only enough to prove some initial concepts. If interested to hear more, we can correspond sometime after getting tqdm's issues sorted out!

It would be great if we can get a HISTORY.md document produced. This would go a long way to clarifying how the project came to be--and how it evolved. Although I suggested Friday as a deadline for gathering initial input, that doesn't mean we can't wait, especially if it means we will include everyone who deserves to be included.

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

@gkthiruvathukal Oh yes, I would be delighted to hear more!

Yes great idea for HISTORY.md, I'll direct my effort towards drafting that then :-)

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

Actually, @casperdcl did a great job documenting changes and PRs in Releases, so maybe we can use that to build a HISTORY.md?

@lrq3000
Copy link
Member

lrq3000 commented Jan 27, 2020

Here's a first attempt HISTORY.md generated by the wonderful github-changelog-generator. It neatly shows the contributor for PR that were merged in. I think this should be usable as a basis to refine :-)

@noamraph
Copy link
Contributor

noamraph commented Jan 27, 2020

Hi everyone, apart from my wish to be listed as an author, I would accept any decision that you take. I have no problem with the list of authors being inclusive. I'm grateful for all the hard work that you spent making my little project into something so awesome!

Regarding history, I first wrote tqdm where I worked, at about 2006. Iterators where pretty new, and I really liked the possibility of showing a progress meter with only adding a few characters. I chose the name "tqdm" because I looked for a short and unique name, and I really like Arabic. (I'm a Jewish Israeli). "tqdm", which is Arabic "تَقَدُّم" in Latin letters, pronounced "taqaddum", simply means "progress".

The small library turned out to be very popular in my work place, so I decided to open source it.

@kmike
Copy link
Contributor

kmike commented Jan 27, 2020

Hey! I think that any arrangement which includes @casperdcl, @noamraph and @lrq3000 as authors and mentions @hadim in some way is fine; their contributions were critical for having tqdm as it is now. It seems most proposals here suggest something similar anyways 👍

@gkthiruvathukal
Copy link

Ok, I am synthesizing here. As you read this, please keep in mind that I do not know any of you personally and am focusing on the input you've given and what git tells us.

I think there is strong consensus for @casperdcl, @lrq3000, @noamraph (probably in that order). Based on my earlier report, I think there is a strong case for @altendky as the 4th author, based on my earlier analysis and his follow up (where he took great care not to say whether he should be a co-author). In his case, however, he seems willing not to be a co-author but has made non-trivial contributions to the success of the project. For this reason alone, I take the view that he should be a co-author. I'm aware that number of commits and lines of code are not the only measures, but in looking at the actual commits, I am convinced his contributions are significant.

As I mentioned, I am hoping to have any and all input by Friday of this week, after which I think @arfon can take the next editorial steps. Based on the information I have in git and on this issue thread, I feel comfortable moving toward these four as co-authors in the order mentioned but would certainly appreciate if all who have commented would react (an emoji will do) to this proposal.

@casperdcl
Copy link
Sponsor Member Author

casperdcl commented Jan 28, 2020

There are two very distinct issues: ongoing maintenance of the library
(paramount importance), and secondly the publication joss.01277.

1) tqdm maintenance practices

  • I absolutely consider all contributors to tqdm (any commits/lines of code/issues/PRs, whether surviving or not) to be "joint authors" of the library. More specifically; joint FOSS copyright holders. This is non-negotiable.

[@altendky] I remembered some funny feelings with some of my contributions. I think the primary missing part [...]

This implies there are other more minor things you haven't mentioned. Please mention them! Also let me know if I haven't responded to any of your other points.

[@altendky] two PRs showed as closed, not merged (#673, #622). The commits they were closed by do show me as author but for some reason have @casperdcl as committer.

Did you check "allow commits from maintainers" when opening your PR? If not, or if I felt there was a lot more work I had to do to tidy up, I would've rebased your commits. This is extremely common good git practice. You will show up as the author (both on the commits and in any metrics such as those generated by GitHub, and those generated by git fame). I want you to show up as the author! You obviously won't be the committer on such rebased/cherry-picked commits unless I do something really clandestine contrary to the design of git. Author takes precedence over committer. Please just take it to mean "the committer's machine was incidentally used at some point."

[@altendky] #674 (adding four words on one line...) was closed and a different solution committed without referencing me (no complaints here).

Yes, it looks like I accidentally independently implemented something which made your PR redundant. Based on the discussion it was also unclear whether it should have been required at all. In any case, at the time, I acknowledged all of this explicitly and also thanked you and added you to the list in the README.

[@altendky] #598 (my only significant contribution) was merged per normal GitHub methods [...] the only comment I would have related to mine is that it would probably be good practice to use the GitHub merge button so it shows up as merged in GitHub

Sort of, I think because you kindly helped with rebasing, debugging and tidying everything so I didn't have to do much!
It wasn't "normal" in the sense that I never use the "merge" button as merging locally and pushing is much more explicit and thus reliable.
I try my best to ensure that whatever I do locally shows up correctly on GitHub but in general don't trust the merged-vs-closed/fixed-vs-closed status of PRs/issues, which is why I use a whole bunch of other metrics when acknowledging contributions.

[@altendky] Should I be an 'author' [...] suspect that the sensible answer is to put me in the 'acknowledgements' group

You are already an author (of tqdm). See my first comment. Regarding joss.01277, though, see the next section (basically happy for you to be acknowledged, and hopefully if JOSS updates their guidelines have you as author).

[@hadim] I hope everyone will get their deserved acknowledgment/authorship without any more drama.

Referring solely to the library (incl. docs/website but not the paper, which I'll address separately below) please let me know if you feel you need more prominent acknowledgement. Let's face it, the library's docs have been viewed over 818 thousand times; several orders of magnitude more than any paper could hope for.

[@gkthiruvathukal] You seem to have a fairly active issue tracker. Perhaps you can look at how many members of the team helped to raise and/or resolve issues.

As I mentioned above, I don't trust the "resolved" status. "Participated" might be a better thing to look for.

[@gkthiruvathukal] sometimes an enormous amount of impact can be made without the singular focus on LOC (or commits). For example, there can be developers who write good tests, configuration scripts, and documentation [...] Did any contributors help, specifically, with user-facing aspects of the software (testing, docs, etc.?)

  • "Sometimes" should be "most of the time."
  • There is no singular focus on LoC, as evidenced by the various other metrics in https://github.com/tqdm/tqdm/#contributions. Let me know if you can think of any others.
  • Tests, configuration scripts, and documentation are all included in my definition of LoC.
  • The website (https://tqdm.github.io/) and associated helper scripts in their entirety were written by me but not included in the LoC though. I have no plans to count this. Let me know if you disagree.

[@gkthiruvathukal] This project is lucky to have such a great group of contributors

  • I find this a highly offensive offhand statement which sounds like a personal attack on all contributors. Luck had nothing to do with it - it took effort.

[@gkthiruvathukal] understand the importance of your software being well-cited

It's not important for FOSS software to be well-cited compared to the importance for it to be well-used.

[@gkthiruvathukal] we don't want to make decisions for you

Yes, I understand you don't want to (and that's within your rights), but the consequences are MUCH worse.

[@noamraph] Regarding history, I first wrote tqdm where I worked, at about 2006 [...] turned out to be very popular in my work place, so I decided to open source it.

I hope you had authorisation from your company https://www.theregister.co.uk/2019/12/12/nginx_moscow_office_raided/.

2) JOSS publication

Oh dear. This is exactly the sort of libellous argument ad-hominem which could have been avoided if JOSS could step in. I understand JOSS is volunteer-run, does great work, and is under no obligation to help, though it would be most useful if JOSS policies are revised to be more helpful.

I have mixed views about various posts in this issue. I am tempted to respond point-by-point, however I believe my views (and indeed anyone else's) are irrelevant to the underlying issue. Attempting to change people's views (in order to avoid the underlying issue) is not something I am comfortable with. Everyone is entitled to their beliefs. Also note that who meets the current and/or future JOSS definition of paper author will unlikely be the same as what anyone feels (i.e. "who do I wish were paper authors" versus "who actually are the paper authors").

To summarise the issue:

  • there is a disagreement about the author list of joss.01277;
  • the contributing parties participating here all seem willing to accept JOSS decision(s)/overruling;
  • JOSS will not overrule/decide;
  • therefore JOSS will withdraw the paper.

There are some considerations which hopefully will make JOSS better:

  1. Introduce explicit guidelines:
    • The IEEE definition of authorship and citation guidelines are a good place to start.
    • Modifications would of course be needed tailored to a FOSS-specific journal.
    • It is unreasonable to expect non-legally trained software devs to discuss this issue with no concrete guidance. It is also unethical to force volunteer FOSS devs to spend time debating this instead of just telling them what to do so they can move on to contributing more code and ideas.
    • Any numeric thresholds (e.g. min 5% LoC contribution), while bound to be wrong, are less wrong than not having thresholds at all (e.g. asking a teacher to mark and accepting marking errors will occur rather than asking students to rank themselves).
  2. Resolve discrepancies between current published guidelines and unpublished internal guidelines/beliefs:
    • Published guidelines https://joss.readthedocs.io/en/latest/review_criteria.html#authorship:
      • submitting author has made a 'substantial contribution' [...] determined by the commit history"

      • the full list of paper authors seems appropriate and complete

      • does not state "all 'substantial' project contributors should be paper authors," which I think would be a harmful requirement but nevertheless something JOSS is entitled to add.
    • Unofficial JOSS comment update paper #887 (comment)
      • [@arfon] It it not the responsibility of the journal to decide who should be an author on a given paper

      • Conflicts with the review criteria. Criteria for deciding are indeed given (but evidently need to be improved upon).
      • [@arfon] authors/contributors of the package are best-placed to decide between themselves

      • Once again seems to be confounding the issue by being ambiguous about whether we are talking about author (which I define to be of a paper) and contributor (which I define to be any activity on GitHub).
      • Also stating that authors should decide who are authors is a tautological logical fallacy.
    • Unofficial JOSS comment update paper #887 (comment)
      • [@gkthiruvathukal] not all contributions can be measured by LOC or number of commits

      • implies JOSS guidelines explicitly mentioning "commit history" need updating to include additional sources.
    • Unofficial JOSS comment update paper #887 (comment) and update paper #887 (comment) and contributor comments update paper #887 (comment) and update paper #887 (comment)
      • [@gkthiruvathukal] probably deserve more than an acknowledgment for your contributions as significant contributors. I always take an inclusive approach to contributions, no matter how large or small. Hopefully, the lead contributors will chime in with whether we could live with the top contributors as minor co-authors

      • [@gkthiruvathukal] I'd like to see as many authors as possible

      • [@altendky] If I get co-author for my one bug-fix then we should look at everyone else that made non-trivial bug fixes and feature additions and include them as well.

      • [@lrq3000] But we need to define a metric indeed. Personally, I would be very glad to see our fellow co-developers in the author list!

      • I fully agree - if paper authors are defined to be code authors then I insist on including the original Zenodo author list (https://doi.org/10.5281/zenodo.2792998). I do not consider anything non-trivial. Permission need not be sought from all code authors if we go down this route as we would be defining paper authors to be code authors, making the paper an accessory to the library rather than a stand-alone journal publication-with-associated-code. Please note that as-is, simply "liking" or "wanting" this to happen is incompatible with the current JOSS guidelines.
    • Contributor comment update paper #887 (comment)
      • [@altendky] Is there something that restricts to co-authors and acknowledgments as opposed to adding a contributors group in between

      • Absolutely agree this is something JOSS should think about.
    • Contributor comment update paper #887 (comment)
      • [@lrq3000] contributed the most to this project, maintained it all this time making it a very successful package used in lots of other applications, and made this paper happen. I think we can all agree that he deserves to be the first author [of the paper]

      • I don't think any of these (apart from the "made this paper happen" and "contributed" -- it's irrelevant that it's "the most") are part of the current JOSS requirements.
  3. Address the difference between a) project author(s), b) project maintainer(s), and c) paper author(s):
    • Definitions of all three are required (e.g. "(c) is expected to be the same as (b)," and "(b) is anyone who has ...,").
    • Zenodo author records need not match JOSS author records unless JOSS updates its authorship definition to include all code contributors. It is wrong to expect the other way around (Zenodo to update its authorship definition to include only a subset of contributors).
    • Consider this hypothetical extreme example:
      • A FOSS project contributor responsible for writing a small yet "significant" (assuming a definition is provided and satisfied) amount of all code, documentation, unit tests, etc wishes to write a paper by themselves.
      • Due to the FOSS licence, this person is not required to seek any permission of anyone, nor are they forced to invite co-authorship (otherwise Python maintainers would be invited co-authors of every Python-based library!).
      • By the IEEE definition of authorship, this person will be the sole author of the paper.
      • By the IEEE citation guidelines and by the FOSS licence terms, they will need to cite the project correctly.

2.1) Conclusions

  • The JOSS requirements could be improved.
  • The JOSS suggestions are trying to redefine and prune a project's full contributor/author/maintainer list to match the purposes of a paper rather than the other way around.

In the absence of any concrete guidance, I can only revert to my own personal code of ethics.

2.1.1) Suggestions

2.1.2) Actions

In the interim period while discussion/decision(s) are ongoing, I will do the following:

  1. Remove

    tqdm/.zenodo.json

    Lines 9 to 12 in 2e58f01

    "creators": [
    {"name": "da Costa-Luis, Casper O.", "orcid": "0000-0002-7211-1557"}],
    "contributors": [
    {"name": "tqdm developers", "type": "Other", "affiliation": "tqdm"}]
  2. Update the table under https://github.com/tqdm/tqdm#contributions.
    • Only minor updates required.
    • This needs to be manually updated (last done in 36b3b7d ~7 months ago).
    • Happy to take suggestions about how to automate the update process, improve, and/or remove the table.
  3. Continue to maintain tqdm amongst other FOSS efforts.

@kmike
Copy link
Contributor

kmike commented Jan 29, 2020

A good point about authors of paper vs authors of the software. I can see how the whole situation could have arised from different expectations here.

From https://joss.readthedocs.io/en/latest/submitting.html:

Your paper should include:
A list of the authors of the software and their affiliations, using the correct format (see the example below).

In the example below a "correct format" is used to define authors with affiliations, which is then shows as authors of the paper. From this I conclude that in JOSS it is expected to have authors of the software as authors of the paper.

https://joss.readthedocs.io/en/latest/review_criteria.html#authorship asks for the list of authors to be reasonably complete. From this it follows that a list of paper authors should be a reasonably complete list of software authors.

Then they ask community to decide what would be a reasonable list of authors. Wording may not be the most precise, but I think then intention is clear. So let's do it :)

How to decide who's an author is subjective, and several approaches are possible. I don't think any legal stuff about authorship matters here. Rules are different in different countries, and we're not in the court. The whole thing is just about fairly acknowledging people for their contributions.

Picking some top contributors, considering their code, discussion and historical contributions looks like a fair way to define an author list. Considering everyone who contributed an author also sounds fine to me. There is also an Acknowledgement section, which can be used to highlight contributions of people who're not in the author list. Alternatively, I think it can be used to highlight top contributors, if "all contributors are authors" approach is taken.

It doesn't look that complicated, after all. Two concrete proposal on how to update the paper, which seems to be in line with the guidelines:

Proposal A.

  1. Put @casperdcl, @lrq3000 and @noamraph as authors.
  2. In the Acknowledgments section put a link to https://github.com/tqdm/tqdm/graphs/contributors and maybe mention that @hadim forked the repo in the dark times.

Proposal B.

  1. Put all contributors to the author list. Getting affiliations can be tricky though.
  2. In the Acknowledgments section say that @noamraph was the original author, @casperdcl has been the main maintainer and contributor in the recent years, @lrq3000 was another prolific contributor, and @hadim forked the repo in the dark times.

@lrq3000
Copy link
Member

lrq3000 commented Jan 29, 2020

@casperdcl , you are shooting yourself in the foot. This situation is your fault, not JOSS's.

This situation arose because you wrote the paper on your own without reaching to any other co-developers, with the exception of me when a JOSS editor requested it. This was evidently an unreasonable procedure.

As you have worked in research, you know that the authors of a paper must include all those who contributed to the experiment. It would be foolish for any of the team member to quickly write a paper secretively, submit it as the sole author, and then claim they are right to do so because noone else contributed to the paper, that's an obvious circular reasoning.

If you had reached to other developers to invite in the writing, and noone would have answered, then it would make for a far better case for you to be the sole paper author. But pre-emptively avoiding contacts barred any other contribution.

So no need for legalese, just common ethical sense. I suggest we stop on this slippery path and come back to fixing the issue at hand. Although @gkthiruvathukal makes suggestions, which I am thankful for, we ultimately are the ones to decide, which is only logical (they only arbitrate).

I agree the Zenodo list of authors can be a good basis, but maybe complemented? Also the order seems subjective, I would like to ensure some degree of objective fairness (if that is at all possible)...

Side-note, about the legal status, if it comes to the worst, the whole project can probably be easily rebased on my minimalist implementation which I made from scratch. I don't know if it still lives here (in the PRs?) but we can certainly find it somewhere.

@altendky
Copy link
Contributor

altendky commented Jan 29, 2020

This implies there are other more minor things you haven't mentioned. Please mention them! Also let me know if I haven't responded to any of your other points.

Even if I did have anything in mind, I'll pass. I stated that you handled my contributions appropriately and what did you do? Rebutted that statement point by point. *boggle* I also commented that while I understand personal preference in workflow that your preference has the presumably unintended side effect of marking PRs as closed rather than merged which can be a bit confusing. Instead of understanding that point you... again, rebutted it.

Please consider not responding to this at all and instead just thinking about the slight feedback on workflow.

[@gkthiruvathukal] This project is lucky to have such a great group of contributors

I find this a highly offensive offhand statement which sounds like a personal attack on all contributors. Luck had nothing to do with it - it took effort.

Clearly that is not an insulting statement. At the same time, there was certainly chance involved in venvs (was it mkenv at the time?) deciding to use tqdm before py2 went eol and capturing the output in the tests thus showing the bug and me being involved enough at that time that I decided to try to fix the issue rather than just dropping use of tqdm, etc.

So, @casperdcl, is the summary of all that you wrote here that you are not clear as to what 'authors' are being discussed and whether they are supposed to be 'the people that wrote the paper' vs. 'the people that wrote the library'? That seems like something that @gkthiruvathukal could probably clear up if it's still in question. Though I haven't been involved in research so I may really be missing something.

@hugovk
Copy link
Contributor

hugovk commented Mar 4, 2020

ping @Separius, @RunOrVeith, @JoshKarpel, @JaviMerino, @EdwardBetts, @AbysmalBiscuit:

Please see #887 (comment), looks like GitHub hit a limit with the long list, so you may not have got the mention. Cheers!

@yarikoptic
Copy link
Contributor

thank you for considering me! But with occasional whining and a single commit (c49021d) I do not consider myself yet deserving the honor! Thank you again and good luck!

@JoshKarpel
Copy link
Contributor

My contribution was also trivial, and I have not reviewed the paper. Please do not add me.

@uadnan
Copy link
Contributor

uadnan commented Mar 4, 2020

Thanks for considering me. And yes, I agree to be a co-author.

@davidbau
Copy link
Contributor

davidbau commented Mar 4, 2020 via email

@EdwardBetts
Copy link
Contributor

Happy to be a co-author.

@anntzer
Copy link
Contributor

anntzer commented Mar 5, 2020

Thanks for the invite, but my contribution (so far) does not warrant authorship; please remove me from the list.

@MPagel
Copy link
Contributor

MPagel commented Mar 5, 2020

* I think affiliations don't apply as there was never any formal institution/org-related collaboration on this completely public-driven FOSS project. Formal authorisation and support was never sought from nor given by any organisation.

In my case, IP rules of my university that I probably signed when I was hired state something to the effect of: if any university resources were used, the contribution I make is not my own. Even if I didn't explicitly sign a document to that effect, these rules are nonetheless in place and govern my ability to maintain employment - i.e. I can be fired if they "find out" that I'm using their resources but going around their back and claiming "ownership" over something. Ostensibly, these rules even apply to the use of e-mail from off-campus outside of normal working hours for non-university related things, but practically speaking they probably only enforceable when I'm sitting at my desk or otherwise "clocked in."

In any case, I used tqdm as part of a script that I was writing at work, for work. The contributions I made stemmed from changes I made to do my job. Ergo, the university owns it. Ergo, my affiliation applies.

This all being said, I'll be leaving the university next month and moving across the country, but there's no need to burn bridges and claim that the little bit of code I contributed is mine and mine alone.

@cheng10
Copy link
Contributor

cheng10 commented Mar 5, 2020

yes, I agree to be a co-author

@kcwu
Copy link
Contributor

kcwu commented Mar 5, 2020

yes, I agree to be a co-author.

Just in case if affiliations or email is needed, please use
Google Inc.
kcwu@google.com

@Separius
Copy link
Contributor

Separius commented Mar 5, 2020

yes, I agree to be a co-author

@hugovk hugovk mentioned this issue Mar 5, 2020
9 tasks
@JaviMerino
Copy link
Contributor

Thank you for considering me 👍 . My contribution was very small. In my opinion I should not be included as co-author.

@to266
Copy link
Contributor

to266 commented Mar 5, 2020

Thank you for considering, but my contribution does not warrant authorship - please remove me from the list.

@casperdcl
Copy link
Sponsor Member Author

casperdcl commented Mar 5, 2020

@MPagel

  1. I've already added your affiliation, as requested
  2. My comment earlier was more about not insisting on (rather than refusing) affiliations

However in your case legally the situation could be potentially far more complex. Given it's a minor contribution it's unlikely that any of this applies, but strictly speaking:

  1. Being inspired in the workplace to develop something in your own time would fall into a grey area where neither party could straightforwardly assert automatic copyright.
  2. In this instance an employer has not asserted copyright over your work. They've (probably) asserted the right to assert copyright. That is, on trust, they assume your work aligns with their goals and ergo may want the affiliation. On the other hand, they may decide (upon "finding out" about your contributions) that the work goes against their principles etc. and that they would want their name and yours removed and, in the extreme case, fire you and/or seek compensation for wasted time because you never sought their permission. In a third scenario, they could decide that your work deserved payment (i.e. you spent company time working on another org's project as a hired contractor), in which case they would seek payment from you rather than the org (since the org was always clear that contributions were FOSS). No matter the scenario, the responsibility unfortunately lies with the contributor.
  3. It's unlikely that a rule about e.g. using a uni email off campus out of hours for unrelated things is legally valid/enforcable. Apart from if you were misrepresenting the uni (e.g. using your account to lend weight or credence to your personal emails) or causing harm (sending large emails which slowed down uni servers) it's unlikely that they can do anything. Most "rules" are either illegal or superfluous (as it turns out the law is surprisingly complete).

Sorry for going off on a tangent but I think I'm as interested in legal theory as you :)

@arunpersaud
Copy link
Contributor

arunpersaud commented Mar 5, 2020 via email

@mikekutzma
Copy link
Contributor

Please don't include me, my contribution doesn't warrant co-authorship.

@willtrnr
Copy link
Contributor

willtrnr commented Mar 5, 2020

Don't include me, I don't consider my contribution to be substantial enough to be a co-author.

@carlinmack
Copy link
Contributor

I agree, ORCID: 0000-0002-9300-0741

@robertzk
Copy link
Contributor

robertzk commented Mar 6, 2020

My contribution was trivial, and I have not reviewed the paper. Please do not add me as a co-author.

@maxnordlund
Copy link
Contributor

Thanks for asking, but I don't think a typo fix qualifies. Please don't add me to the paper.

@MPagel
Copy link
Contributor

MPagel commented Mar 6, 2020

@casperdcl

@MPagel
...

Sorry for going off on a tangent but I think I'm as interested in legal theory as you :)

Your take is probably correct. In my particular case, there's 0% chance they would find my open source software participation problematic, as the unit I work with is all about promoting the 'sister' to OSS: open data. They might have issue with the balance of time I spend on certain tasks, but they hired me for who I am.

Edit: thank you also for clarifying your stance re: affiliation. I had noticed that my affiliation had been included as requested, but wasn't certain if that was just a temporary appeasement or not;) Your response clarifies your intent and I agree that your take on the topic seems appropriate.

@dwhswenson
Copy link
Contributor

Thanks, I'd be happy to be listed as an author. My contribution was small, but if you and the journal think it's enough, I'm pleased to be included.

Name: David W.H. Swenson
Affiliation: Univ Lyon, ENS de Lyon, Univ Claude Bernard, CNRS, Laboratoire de Physique and Centre Blaise Pascal

(That's really one affiliation, even though it looks like more. But it's what they tell me to put on papers.)

Personal aside: I'm actually quite proud of my (tiny) contribution to tqdm. It was exciting to contribute to a project with such wide impact. And the existing code was clear enough that it was as easy for me to fix the problem as it would have been to write an issue explaining it.

@RunOrVeith
Copy link
Contributor

I contributed support for explicitly known infinite iterators.
If you think this warrants a contribution, I'd be happy to be included.

Name: Veith Röthlingshöfer
ORCID: 0000-0002-1824-3153

Is there a way to review/read the paper before publishing?

@danking
Copy link
Contributor

danking commented Mar 8, 2020

I decline co-authorship, but am grateful for this project and the thought you’ve put into this process. Godspeed!

@rlmaers
Copy link
Contributor

rlmaers commented Mar 9, 2020

Don't include me.

@hugovk
Copy link
Contributor

hugovk commented Mar 9, 2020

Is there a way to review/read the paper before publishing?

@RunOrVeith, the source is here:

There's a proof here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question/docs ‽ Documentation clarification candidate
Projects
None yet
Development

Successfully merging a pull request may close this issue.