¿Cuál es la etiqueta para enviar preguntas por correo electrónico repetidamente a un autor cuyo trabajo estoy desarrollando?

Aunque probablemente tus intenciones sean buenas, parece que te aprovechas del creador del código fuente. No es tu depurador personal ni debe ser el que escriba el código de tu tesis (especialmente si es gratis). Ha escrito un artículo y te ha dado su código fuente. Esa es toda la información que necesitas saber. Lea su artículo (o sus diapositivas si están disponibles públicamente) cien veces, hasta que conozca cada pequeño detalle y luego mire su código (otras cien veces) hasta que correlacione todo entre el artículo y el código. Por supuesto, esto será más lento que enviarle un par de correos electrónicos, pero es SU tesis, no la suya. Solo cuando haces todo esto y todavía hay preguntas sin respuesta, luego recopile todas las posibles preguntas que pueda tener (incluidas las consultas sobre su código y su papel) y luego envíele UN correo electrónico, con todas sus preguntas. Cualquier cosa más que eso es explotar su amabilidad. Este tipo de correos electrónicos de ida y vuelta con preguntas es una de las muchas razones por las que muchas personas no están dispuestas a compartir su base de código.

Dado que probablemente sea un buen tipo, debes considerar que en el futuro podrías colaborar con él o necesitar su ayuda. Ser agresivo o perezoso (y delegarle su trabajo porque no quiere pasar de 1 a 3 semanas refactorizando o estudiando su código con más cuidado) es una forma segura de quemar puentes con él. Y realmente no quieres hacer eso.

Por otro lado, si después de darte acceso a su código fuente entiende (a través de tu correo electrónico) que hiciste todo lo humanamente posible para entender su código y papel y solo desea ayuda adicional, estará dispuesto a ayudarte porque: a) pareces apreciar su trabajo b) pareces entender sus limitaciones de tiempo c) también eres un tipo inteligente y trabajador con el que vale la pena colaborar. Y este es el mensaje que debes transmitir.

¿Por qué no solo preguntarle a él? Sabe lo ocupado que está, lo interesante que es tu proyecto para él y lo tontas ( si las hay) que son tus preguntas. También puede ofrecerle pagarle escribiendo un manual (parcial) sobre su código, a medida que lo entienda.

Si recibiera este tipo de correos electrónicos, vería que están reconociendo mi esfuerzo y tratando de ser respetuosos con mi tiempo. Y tal vez esto sea bueno para mí, obligándome a repensar aspectos del código y hacer una nota mental de hacer una mejor documentación en el futuro.

Además, en esa situación, agradecería mucho que me mantuvieran informado sobre su proyecto. Incluso si no puedo o no quiero ayudar, me gustaría ver el progreso.

Una respuesta rápida suele ser una buena señal, significa que él encuentra tus preguntas interesantes y no algo que deberías haber podido resolver por ti mismo. En cualquier caso, si quiere asegurarse, puede preguntarle a alguien que esté más o menos familiarizado con ese código (probablemente su asesor) y ver si las preguntas son realmente algo que debería haber podido resolver por sí mismo; y si no lo eres, que te enseñen las técnicas que te faltan para hacerlo.

Dicho todo esto, me han dado un código desordenado para trabajar tres veces, y las tres terminé tomando el papel y reimplementándolo yo mismo en un par de días (y en dos de ellos, el resultado fue mucho mejor). Tal vez tu caso sea demasiado grande, pero deberías considerarlo.

Como alguien que a menudo es el receptor de este tipo de preguntas, mi consejo es:

1. En primer lugar, comprenda la teoría detrás del código antes de hacer preguntas. Muchas de las preguntas que recibo sobre mi código revelan que la persona con la pregunta simplemente no tiene conocimientos básicos de optimización (p. ej., "¿qué es una factorización de Cholesky?") sin los cuales no podría entender el código.

2. Asegúrese de tener la última versión del código del autor. No utilice una versión anterior.

3. Comprenda cómo se otorga la licencia del software (si es que lo hace). Tendrá que trabajar dentro de los términos de esa licencia (por ejemplo, el autor podría haber puesto el código bajo la GPL, y su trabajo derivado también tendrá que ser GPL).

4. No se queje de la calidad del código o de las funciones que le faltan. Si no hace lo que necesita, pregúntele al autor si esto es posible dentro del código actual, o por una extensión simple o si el algoritmo fundamentalmente no maneja ese caso o lo que sea. No asumas que lo que quieres será fácil o incluso posible. Según la respuesta del autor, es posible que obtenga una solución lista para usar, o que obtenga información sobre cómo modificar el código, o que le digan que no es práctico.

5. Si recibe errores, proporcione los datos de entrada y salida para que pueda recrear el problema. Haga un ejemplo que reproduzca el problema de la manera más simple posible en lugar de darme todo su código. Intentaré recrear el problema en mi máquina.

Hasta cierto punto, probablemente estoy repitiendo lo que otros ya han dicho aquí. Pero en cualquier caso, aquí voy con mis 2 centavos.

Primero, la situación que describes es bastante inusual. En la mayoría de los casos en los que se utiliza código en una publicación, el código no se publica y, si no se publica, a menudo no se puede obtener de los autores. Si lo proporcionan, no es muy probable que respondan preguntas al respecto. Por ejemplo, a menudo el código lo escribe una persona joven como un estudiante de posgrado, y una vez que esa persona se ha ido, los autores principales, que también son el autor de correspondencia, no saben nada específico sobre el código, porque en realidad no lo han hecho. escrito nada de eso. También es posible que ya no tengan una copia, si es que alguna vez la tuvieron.

Entonces, ya estás en una buena situación, que alguien te está respondiendo.

Otra cosa a tener en cuenta es que a los académicos les gusta que la gente se interese por tu trabajo. Dado que su corresponsal escribió el código, probablemente sea el autor principal del trabajo; las personas que escriben el código generalmente lo son. Por lo tanto, es posible que no le importe responder preguntas sobre su trabajo siempre que no sean estúpidas. Evite preguntas básicas/generales relacionadas con el lenguaje que no sean específicas del código, por ejemplo.

Como dijo alguien más, si quieres saber cómo se siente, ¿por qué no preguntarle? Entonces, sugeriría tres cosas concretas.

1. Exprese su agradecimiento por el tiempo que dedica a responderle. No te excedas; una frase o dos es suficiente. Pero es importante hacerlo.
2. Si está interesado/dispuesto a tenerlo como coautor, pregúntele si está interesado en ser coautor. Si no está interesado, o no lo quiere como coautor, pídale permiso para agregarlo a los agradecimientos. Ciertamente deberías agregarlo, si él está de acuerdo.
3. Pregúntele si está bien seguir haciéndole preguntas ocasionales. Tal vez describa qué y cuánto espera preguntarle, si tiene una idea, para que sepa qué esperar.
4. Esto va más allá, en cierto sentido, pero dado que usted dice que su código no está documentado, documéntelo, tal vez consulte con él primero sobre cómo hacerlo, en caso de que tenga preferencias. Luego, envíale la documentación. Esa es una buena manera concreta de mostrar aprecio.