Где провести черту авторства для документа, анонсирующего программное обеспечение?

В настоящее время я работаю над научным программным обеспечением, для которого я хочу опубликовать анонс программного обеспечения в соответствующем журнале. В то время как я выполняю и, вероятно, буду продолжать выполнять подавляющую часть работы, возможно, что другие внесут свой вклад таким образом, что возникнет вопрос об их авторстве в статье. Чтобы избежать разногласий и последующих вопросов, я хотел бы обсудить авторство как можно раньше, если такой вклад кажется правдоподобным.

В обычной статье центральным критерием авторства является интеллектуальный вклад, в то время как технический вклад, такой как простая программная реализация некоторого существующего алгоритма, не соответствует требованиям. Более того (по крайней мере, в моей области) довольно нетипично, что кто-то вносит лишь небольшой вклад в статью, так что серая зона авторства редко является проблемой.

Однако в документе, анонсирующем программное обеспечение, я могу выделить несколько аспектов, которые можно было бы считать важными, и участников, чьи участники могли бы считаться подходящими для авторства:

  • Разработка новых алгоритмов и подходов. Хотя это явно интеллектуальный вклад, который может даже оправдать отдельную статью, не все новые научные программы имеют такую ​​возможность. Следовательно, это не может быть единственным аспектом, определяющим авторство.

  • Выбор алгоритмов и методов для реализации.

  • Разработка интерфейса, обычно нацеленного на какое-то конкретное научное приложение.

  • Собственно написание софта.

  • Тестирование программного обеспечения. Учитывая приложение, поиск подходящих тестовых случаев с известным поведением сам по себе может быть проблемой.

  • Написание фактической бумаги.

Более того, гораздо более вероятно, что кто-то внесет небольшой вклад в серую зону, например, исправит ошибку, предоставит пример для документации или тестирования, предложит функцию или что-то подобное. Это относится, в частности, к случаям публикации разрабатываемых версий программного обеспечения.

В моем целевом журнале нет никаких указаний по этому поводу, и я не смог найти никаких общих правил в Интернете. Поэтому я спрашиваю, существуют ли какие-либо хорошие (предпочтительно установленные) рекомендации по определению авторства такой статьи, в частности, относительно того, какой тип вклада вообще может претендовать на авторство и где провести черту.

У меня нет времени на полный ответ, но эти ссылки могут быть полезны для рассмотрения в мире разработки программного обеспечения для исследований: software.ac.uk/tags/software-research-object и rse.ac.uk/index.html
«Тестирование программного обеспечения. Учитывая приложение, поиск подходящих тестовых случаев с известным поведением сам по себе может быть проблемой». Разве он не включает всех ваших пользователей на каком-то уровне?
@T.Verron: … что только иллюстрирует, насколько сложно рисовать линию.
См. ivory.idyll.org/blog/2015-authorship-on-software-papers.html для обсуждения этого: там много комментариев.
Другой более свежий пост, который немного шире, чем «одна статья», но затрагивает проблему, — medium.com/@matthewturk/… .
Я опубликовал программное обеспечение с открытым исходным кодом для научных кругов. Что я сделал, чтобы каждый мог получить признание за случайный/будущий вклад, так это создал функцию под названием «citeme (имя метода)». Это напечатает статью человека, который внес свой вклад в мое программное обеспечение, таким образом удостоверившись, что любой, кто использует программное обеспечение, отдает ему должное.

Ответы (1)

Как показывает обсуждение под этим постом , не существует набора установленных правил в рамках одного подполя, не говоря уже о всех академических кругах, относительно того, где провести черту.

Другой, не связанный с этим вопрос: чего вы пытаетесь достичь этой статьей?

Если речь идет о попытке правильно распределить заслуги в работе, проделанной при создании программного обеспечения, то это трудная проблема: есть работа FORCE11 Software Citation Group и их статья . Но по мере того, как программное обеспечение растет и изменяется, вам придется продолжать принимать эти решения.

Если речь идет о росте сообщества вокруг программного обеспечения, его улучшении, привлечении большего числа людей к его использованию и внесению своего вклада, то здесь есть вдумчивый пост . Это гораздо больше, чем просто документ, но он отмечает множество проблем с предоставлением надлежащего кредита, когда проект программного обеспечения обновляется и члены сообщества меняются.

Мое мнение , насколько оно того стоит: чем шире вы распространяете авторские приглашения и чем шире вы это делаете, тем больше вероятность того, что вы получите одобрение сообщества и поддержку в будущем. Делая четкие ожидания относительно конкретного вклада в сам процесс написания статьи, вы можете уменьшить количество конфликтов, связанных с проблемой безбилетника.

+1 Мне нравится подход группы разработчиков к цитированию в качестве абстрактной группы, поскольку это объявление, для меня имеет больше смысла видеть команду разработчиков. (2017). «Супер полезное научное программное обеспечение», Журнал научного программного обеспечения, а не какой-то длинный список имен, которые обсуждаются. Кроме того, говоря как о человеке, который раньше выполнял такую ​​работу, это экономит внутреннюю политику в отношении того, кто включен, а кто нет, и позволяет людям, которые хотят продолжать заниматься академическими ролями, некоторый (крайне незначительный) корм для резюме.
Я все еще работаю над вашими ссылками. Не могли бы вы сформулировать или обобщить политику, предложенную или используемую ими (например, у авторов этого поста есть политика предлагать авторство всем, кто вносит свой вклад в репозиторий GitHub).
Этот пост - единственный, который (насколько я помню) определяет политику, которая не является глубоко специфичной для человека или области.