PeerJ R3C6

[kyleniemeyer]

in addition to thoughts on versions, has the journal developed a strategy on software forking, in particular by different developer teams to the original developers?

[arfon]

Not really but in theory I think we would consider a publication from a fork. This gets into the tricky territory of JOSS policing authorship (which is never going to be easy).

We might want to add a small paragraph mentioning that while a Git history (or similar) makes it easy to suggest people who should possibly/probably be authors, ultimately authorship is hard and subjective and depends upon the given situation.

[danielskatz]

We could say that the list of contributors and list of authors is often not the same, and give examples of contributors who should not be authors (e.g., someone who modifies the license file) and non-contributors who should be authors (e.g., a member of the design team for the software)

Although thinking about it again, I'm not sure this really goes in this issue :)

[kyleniemeyer]

OK, how about this as a new paragraph at the end of the discussion section?

The discussion about new software versions also generally applies to software forks, where software is copied and, after some divergent development, a new software package emerges. Similar to how we handle new software versions, the \joss{} editorial board will consider publication of articles describing a fork if it includes substantial changes from a previously published version. Authorship questions may be more challenging when dealing with forks compared with new versions, since forks can retain varying amounts of code from the original projects. However, while a version control history generally makes it easy to suggest people who should be authors, ultimately deciding on authorship is hard and project-dependent. We prefer to leave authorship decisions to the projects.

[kyleniemeyer]

And the response:

We have added a short paragraph to page 17 describing how we might handle submissions of software forks. Ultimately, we prefer to leave authorship decisions to the developers, though this could become challenging for forks.

[arfon]

👍 LGTM. I did a small amount of word-smithing:

The discussion about new software versions also generally applies to software forks, where software is copied and, after some divergent development, a new software package emerges. Similar to how we handle new software versions, the \joss{} editorial board will consider publication of articles describing a fork if it includes substantial changes from a previously published version. Authorship questions may be more challenging when dealing with forks compared with new versions, since forks can retain varying amounts of code from the original projects. However, while a version control history generally makes it easy to suggest people who should be authors, deciding on authorship can be difficult, subjective, and is therefore ultimately project-dependent. We prefer to leave authorship decisions to the projects.

[danielskatz]

suggestion:

The discussion about new software versions also generally applies to software forks, where software is copied and, after some divergent development, a new software package emerges. Similarly to how we handle new software versions, the \joss{} editorial board will consider publication of an article describing a forked version of software if it includes substantial changes from a previously published version. Authorship questions may be more challenging when dealing with forks compared with new versions, since forks can retain varying amounts of code from their original projects. However, while a version control history generally makes it easy to suggest people who should be authors, deciding on authorship can be difficult, subjective, and is therefore ultimately project-dependent. We prefer to leave authorship decisions to the projects, with discussion taking place as needed with reviewers and editors.