¿Cuál es el umbral para que un artículo de software sea publicable?

Me han pedido que evalúe un artículo sobre una herramienta de software. Estoy luchando para saber si este trabajo en particular es suficiente para justificar su publicación. La revista para la que estoy reseñando no tiene un criterio de "notabilidad/novedad", pero sí requiere que el trabajo sea una "unidad de publicación".

Llamemos a lo que estoy revisando "Característica". La característica es parte de un paquete más grande, llamémoslo "Paquete". Feature es una herramienta de GUI que toma los datos que ya ha calculado Package y los traza utilizando un backend de trazado ampliamente utilizado. Tiene algunas cosas interesantes que exponen opciones en el backend de trazado como elementos GUI, y algunas opciones relacionadas con la naturaleza del trazado que se está realizando (gráfico de dispersión frente a mapa de calor, básicamente, además de algunas alternancias basadas en etiquetas específicas de dominio en los datos) .

Aquí hay algunos hechos que están dando forma a mi punto de vista:

  1. Esencialmente no hay lógica científica en Feature. Necesita poder leer los archivos, opcionalmente multiplicar por un peso, y luego tiene algunos cambios almacenados en los datos para cambiar qué datos se presentan. Pero es principalmente una GUI muy simple para analizar datos de visualización de Package.
  2. La totalidad de la función tiene menos de 1400 líneas de código, y casi la mitad es específica de la GUI.
  3. Mirando el código, (especialmente no GUI), sospecho que podría cortar alrededor de 300-400 líneas de código: los desarrolladores no están usando las herramientas de software científicas disponibles, incluida la reimplementación de una función que está en una biblioteca que incluyen.
  4. Actualmente, un documento sobre la versión del Paquete X.0 está bajo revisión por pares (X>1); citado en el manuscrito que estoy revisando. Todos los autores del artículo sobre Característica también son autores del artículo sobre Paquete.
  5. La lista completa de autores de Package es esencialmente un grupo de investigación; este no es un gran esfuerzo de toda la comunidad. Y el documento sobre la versión X-1 del paquete se publicó hace solo 2 años, por lo que me sorprende que ya estén tratando de publicar dos documentos de software más.

Los dos últimos me molestan especialmente, porque siento que el propósito de los artículos de software científico es hacer que el desarrollo de software científico sea citable, no aumentar la cantidad de artículos. Los autores ya recibirán las citas basadas en el otro artículo.

Por otro lado, llegué a esto con cierto sesgo de que uno de los autores tiene tendencia a preocuparse más por la cantidad que por la calidad de las publicaciones. Así que no estoy seguro de si mi inclinación hacia el rechazo se basa parcialmente en eso o en los hechos sobre el terreno. (De ahí el deseo de otras opiniones.)

EDITAR: olvidé decir que la función aún no se fusionó con la rama principal del paquete, pero actualmente está en una rama separada en el mismo repositorio de git.

¿Se podría usar la característica en datos no generados por el paquete?
@AzorAhai En teoría. Si los datos usaron el mismo formato de salida que Paquete (archivos de texto organizados en el sistema de archivos de cierta manera). El paquete es una reescritura moderna de OldFortranCode, por lo que la salida de OldFortranCode también funcionará. Pero no sería compatible con el principal competidor de Package (a menos que alguien escriba el software de traducción). EDITAR: Aclarar: OldFortranCode solo se usó en grupo; por lo que no tiene base de usuarios.
Entonces, ¿esperaría que las personas de otros grupos alguna vez usaran Feature para trazar sus datos?
La función está diseñada principalmente para usuarios de Package. Otros grupos utilizarán el Paquete y, por lo tanto, la Característica (la Característica se distribuirá como parte del Paquete). En principio, alguien podría agregar un traductor Competidor -> Paquete. Pero Competitor es una biblioteca de Python y, por lo tanto, tiene acceso inmediato para trazar con matplotlib, por lo que no estoy seguro de que su base de usuarios (de la cual soy miembro) lo exija.
Supongo que realmente no tengo nada que agregar más allá de la respuesta de Buffy entonces. Parece que conoce el problema bastante bien y esto podría ser un relleno de recuento de publicaciones.
Algo que he hecho: puede escanear artículos publicados recientemente en la revista (digamos, en los últimos 5 o 6 años) y ver en qué medida sus preocupaciones con este artículo aparecen en cualquiera de estos otros artículos. Pero tal vez para su campo y tema (del cual no sé nada), esto podría ser algo difícil de determinar al mirar rápidamente un documento. Dicho esto, mi reacción instintiva al leer sus inquietudes (p. ej., el n.° 3 me parece especialmente problemático) es que este documento tiene varias deficiencias aparentes, que pueden no ser deficiencias, pero es razonable esperar que los autores las defiendan.
@DaveLRenfro: Buena idea, ya había hecho algo de eso. La revista secundaria específica es un nuevo miembro de la "familia" de la revista, pero hojeé artículos recientes sobre software en revistas hermanas/principales, así como en otras revistas de publicación de software en el campo. Algunos documentos eran un poco pequeños para mi gusto, pero generalmente se justificaban por ser de uso muy general o por ser el primer anuncio de un nuevo código. No vi características nuevas únicas del código existente. Dicho esto, solo me di cuenta de lo débil que era este una vez que comencé a revisarlo.
Re: #3: Eso es dolorosamente común, según mi experiencia. La gente no conoce sus herramientas, y el resultado son pulsaciones de teclas desperdiciadas y código difícil de mantener. Lo enumero aquí porque es relevante para usar líneas de código como una estimación del estado de "unidad". No rechazaría un artículo basado únicamente en un código mal escrito. Lo menciono en la revisión y señalo mejores herramientas/recursos educativos. El problema es institucional, no individual: los científicos de software fueron capacitados como científicos y no conocen el lado del software.

Respuestas (2)

No existe un umbral de línea brillante para tales cosas y la respuesta debería ser la misma que para cualquier artículo científico, dependiendo de cuestiones de novedad y extensión del conocimiento. Si no tiene eso, entonces probablemente no sea un buen candidato, aunque los estándares de las diferentes revistas varían ampliamente.

Pero parece describir un avance pequeño, si es que lo hay, con poca novedad y también parece haber tomado una decisión. No podemos ayudarlo con el juicio y solo necesita arriesgarse y llamarlo. Es posible que otros no estén de acuerdo con usted, pero ese es siempre el caso al revisar.

Realmente no entiendo su punto 5 y podría estar en desacuerdo con su énfasis en él. ¿Por qué el trabajo realizado dentro de un grupo es menos valioso que el trabajo que cruza las líneas institucionales? Muchos trabajos son realizados por una o unas pocas personas dentro de un grupo de investigación. Sin embargo, podría estar más de acuerdo si quiere decir que todos sus artículos citados provienen de esas mismas personas. Eso no es necesariamente una bandera roja, pero podría serlo.

Lo siento, para aclarar el punto 5: lo digo en el sentido de que si Package tuviera 100 autores, entonces los autores de Feature podrían sentir que sus contribuciones se están perdiendo en la mezcla, y podría entender por qué sintieron que se necesitaba un segundo artículo para destacar sus aportes. Con ~6 autores, sus contribuciones no serán ignoradas.
Además, editado para aclarar que la revista prohíbe explícitamente considerar la novedad. (También impacto, enfoque estrecho, etc.)
Parece bastante amplio. ¿ Es entonces aceptable cualquier cosa que sea correcta y no rompa las normas?
Sí. La revista tiene la intención de fomentar la publicación de intentos de replicación de experimentos anteriores (suponiendo que se pueda dar una justificación para la replicación) y permite resultados negativos/no concluyentes. Así que no quieren que el impacto/novedad sea una medida de aceptación. Entiendo la intención de los experimentos, pero me resulta difícil con los documentos de software. Así que estoy tratando de encontrar una mejor prueba para "¿es esto una contribución suficiente para una publicación?" que "mi instinto dice...".
Y antes de que preguntes (porque sería mi siguiente pregunta), la revista es legítima. O no fue hace mucho. Verifiqué que uno de los premios Nobel que enumera la revista principal todavía incluye la revista principal como una de sus asignaciones editoriales.

Voy a aceptar la respuesta de Buffy, porque incluso si no es la respuesta de "así es como ponértelo más fácil" que esperaba, parece ser la respuesta correcta generalmente acordada.

Dicho esto, después de pensarlo mucho (y considerando los comentarios de aquí), he creado una lista que me satisface bastante. Supongo que todo después de los dos primeros puntos es más para verificar "¿hay alguna novedad/notabilidad aquí que estés pasando por alto porque tu reacción instintiva es que esto no es suficiente trabajo para contar como un trabajo?"

  • ¿Esto implementa alguna ciencia no trivial? Si la herramienta implementa una generación de datos significativa o una lógica de análisis de datos, entonces se debe considerar. "Significativo" sigue siendo un término subjetivo, pero solo leer un formato de salida no sería significativo.
  • ¿La herramienta de software se distribuye de forma independiente? Un propósito importante de los documentos de software es hacer que la comunidad conozca los complementos que de otro modo no se notarían (perdidos en algún rincón oscuro de Internet). Estos pueden ser fragmentos de código relativamente pequeños (pero útiles) que se pasarían por alto sin un diario que sirva como foro de anuncios. Este criterio probablemente solo sea aplicable a los casos extremos.
  • ¿Es la herramienta reutilizable en muchos contextos? Incluso una herramienta muy simple puede ser una contribución valiosa si está diseñada para facilitar la interoperabilidad. Por ejemplo, un "traductor universal" simple para formatos específicos de dominio puede ser muy pequeño, pero vale la pena publicarlo.
  • ¿El enfoque es novedoso? Incluso para las revistas que no tienen un requisito de novedad , la existencia de un enfoque novedoso puede ser una consideración a la hora de aceptar un artículo.
  • ¿La implementación de la herramienta requiere una experiencia significativa en el dominio? Un propósito potencial de una publicación de software científico es empaquetar experiencia significativa en el dominio de una manera que esté disponible para personas que no son expertas.

Para el quinto punto, imagino algo como una GUI que evita que los usuarios seleccionen opciones incompatibles, donde las incompatibilidades pueden requerir experiencia en el dominio. Sé que en mi campo tenemos programas de generación de datos basados ​​en secuencias de comandos donde los usuarios pueden seleccionar accidentalmente opciones incompatibles y obtener tonterías como resultado.

No estoy seguro de que esto cubra todos los casos, pero cubre todo lo que se me ocurre. Y me siento mejor al haber usado una rúbrica que podría aplicar a cualquier paquete de software.

¡Publicar con la esperanza de recibir comentarios de la comunidad, para que la siguiente persona en una situación similar pueda ver lo que hice!

¿Cuál es el umbral para que un artículo de software sea publicable?
RespuestasAquíPolítica de privacidad1y, 0v