¿Dónde trazar la línea para la autoría de un documento de anuncio de software?

Actualmente estoy trabajando en un software científico, para el cual quiero publicar un artículo de anuncio de software en una revista relacionada. Si bien estoy haciendo y probablemente seguiré haciendo la gran mayoría del trabajo, es posible que otros contribuyan de una manera que plantee la cuestión de su autoría en el artículo. Para evitar desacuerdos y problemas posteriores, discutiría la autoría lo antes posible si tal contribución parece plausible.

En un artículo regular, el criterio central para la autoría son las contribuciones intelectuales, mientras que las contribuciones técnicas, como una implementación de software sencilla de algún algoritmo existente, no califican. Además (al menos en mi campo), es bastante atípico que alguien contribuya solo con una pequeña parte de un artículo, por lo que la zona gris de la autoría rara vez es un problema.

En un documento de anuncio de software, sin embargo, puedo pensar en varios aspectos que podrían considerarse esenciales y contribuyentes a los que podrían considerarse elegibles para la autoría:

  • Desarrollo de nuevos algoritmos y enfoques. Si bien esto es claramente una contribución intelectual e incluso podría justificar un artículo por sí solo, no todos los nuevos software científicos presentan tal cosa. Por lo tanto, no puede ser el único aspecto que califica para la autoría.

  • Elegir los algoritmos y métodos a implementar.

  • Diseñar la interfaz, generalmente dirigida a alguna aplicación científica particular.

  • En realidad escribir el software.

  • Prueba del software. Dada la aplicación, encontrar casos de prueba adecuados con un comportamiento conocido puede ser un desafío en sí mismo.

  • Escribir el papel real.

Además, es mucho más probable que alguien haga una pequeña contribución de zona gris, como corregir un error, proporcionar un ejemplo para la documentación o la prueba, sugerir una función o algo similar. Esto se aplica en particular si se publican versiones de desarrollo del software.

Mi diario de destino no proporciona ninguna orientación sobre este asunto y tampoco pude encontrar reglas generales en Internet. Por lo tanto, pregunto si existen buenas pautas (preferiblemente establecidas) para decidir la autoría de un artículo de este tipo, en particular sobre qué tipo de contribuciones pueden calificar para la autoría y dónde trazar la línea.

No tengo tiempo para una respuesta completa, pero estos enlaces pueden ser útiles para su consideración en el mundo de la ingeniería de software de investigación: software.ac.uk/tags/software-research-object y rse.ac.uk/index.html
"Probar el software. Dada la aplicación, encontrar casos de prueba adecuados con un comportamiento conocido puede ser un desafío en sí mismo". ¿No incluye a todos sus usuarios en algún nivel?
@T.Verron: … lo que ilustra lo difícil que es trazar la línea.
Ver ivory.idyll.org/blog/2015-authorship-on-software-papers.html para una discusión sobre esto: hay muchos comentarios.
Otra publicación más reciente que es un poco más amplia que "un documento", pero que aborda el problema, es medium.com/@matthewturk/… .
He publicado un software de código abierto para la academia. Lo que hice para asegurarme de que todos pudieran obtener crédito por contribuciones aleatorias/futuras fue crear una función llamada "citeme(methodname)". Esto imprimirá el documento de la persona que contribuyó con su método a mi software, asegurándome así de que cualquier persona que use el software le dé crédito.

Respuestas (1)

Como muestra la discusión debajo de esta publicación , no hay un conjunto de pautas establecidas dentro de un solo subcampo, y mucho menos en toda la academia, en cuanto a dónde trazar la línea.

Una pregunta diferente, no desvinculada: ¿qué está tratando de lograr con este documento?

Si se trata de repartir correctamente el crédito por el trabajo realizado en la producción del software, entonces este es un problema difícil: está el trabajo del FORCE11 Software Citation Group y su artículo . Pero a medida que el software crece y cambia, tendrá que seguir tomando estas decisiones.

Si se trata de hacer crecer una comunidad en torno al software, mejorarlo, hacer que más personas lo usen y contribuyan, aquí hay una publicación reflexiva . Eso es mucho más que un artículo, pero señala muchos problemas para dar el crédito adecuado cuando se actualiza un proyecto de software y los miembros de la comunidad cambian.

Mi opinión , por lo que vale: cuanto más ampliamente extiendas las invitaciones de autoría , y cuanto más ampliamente se vea que lo haces, más probable es que obtengas la aceptación de la comunidad y el apoyo futuro. Al dejar claras las expectativas sobre las contribuciones concretas al proceso mismo de redacción del artículo, puede reducir los conflictos en torno al problema del oportunista.

+1 Me gusta el enfoque del grupo de desarrollo que obtiene la cita como un grupo abstracto, ya que este es un anuncio, tiene más sentido para mí ver el Equipo de desarrollo. (2017). "Software científico súper útil", Journal of Scientific Software que una larga lista de nombres que se debaten. Además, hablando como alguien que solía hacer este tipo de trabajo, ahorra en la política interna sobre quién está incluido y quién no y permite que las personas que quieren continuar con funciones académicas formen un currículum (extremadamente menor).
Todavía estoy trabajando a través de sus referencias. ¿Podría indicar o resumir las políticas sugeridas o empleadas por ellos (por ejemplo, los autores de esta publicación tienen la política de ofrecer autoría a todos los que contribuyen al repositorio de GitHub).
Esa publicación es la única que (según recuerdo) especifica una política que no es profundamente específica de una persona o campo.